ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / syncronized vs volatile с точки зрения visibility
25 сообщений из 135, страница 3 из 6
  3  все
syncronized vs volatile с точки зрения visibility
    #39395373
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
questionerтак мы можем долго разбираться, давайте Вы приведете пример с volatile, где мы увидим, что изменение не гарантировано и обсудим действительно ли оно не гарантировано. И как этот флаг будет использоваться.

Отсутствие гарантий нельзя проверить. Ещё раз- при любом эксперементе, скорее всего, Вы проблем не увидете. Они вдруг случатся в продакшене.

questionerЗачем мне, разработчику на java, задумываться о тактах процессора? сброс кешей хоть упрощает понимание происходящего, а такты то мне зачем?

И не надо. Есть гарантии JMM - это всё, что надо знать.


questionerну и значит ли Ваша фраза про флаги, что есть смысл только в boolean volatile ?
В других случаях я не очень понимаю как мы будем понимать чего нам ждать

Нет, не значит. Это значит, что мы не можем знать, как скоро второй поток увидет изменения переменной в первом потоке.
Но если второй поток это увидел- у нас появляются гарантии.
...
Рейтинг: 0 / 0
31.01.2017, 12:51
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395403
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
questioner
Гость
Alexey Tominquestionerтак мы можем долго разбираться, давайте Вы приведете пример с volatile, где мы увидим, что изменение не гарантировано и обсудим действительно ли оно не гарантировано. И как этот флаг будет использоваться.

Отсутствие гарантий нельзя проверить. Ещё раз- при любом эксперементе, скорее всего, Вы проблем не увидете. Они вдруг случатся в продакшене.

questionerЗачем мне, разработчику на java, задумываться о тактах процессора? сброс кешей хоть упрощает понимание происходящего, а такты то мне зачем?

И не надо. Есть гарантии JMM - это всё, что надо знать.


questionerну и значит ли Ваша фраза про флаги, что есть смысл только в boolean volatile ?
В других случаях я не очень понимаю как мы будем понимать чего нам ждать

Нет, не значит. Это значит, что мы не можем знать, как скоро второй поток увидет изменения переменной в первом потоке.
Но если второй поток это увидел- у нас появляются гарантии.

Я понимаю, что эксперимент приведет к провалу, но давайте таки посмотрим на код и умозрительно оценим с точки зрения наших знаний и HB.

Без конкретики тяжело говорить.

----------------------------------------------

Кстати по поводу DCL и входа в synchronized секцию:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class Something {
    private static Something instance = null;
    public static Something getInstance() {
        if (instance == null) {
            synchronized (Something.class) {
                if (instance == null)
                    instance = new Something();
            }
        }
        return instance;
    }
    ....
}



внутри synchronized (Something.class) мы же всегда увидим корректное значение?

То есть то, что DCL без volatile не работает это всего лишь то, что нам придётся захватывать лишний раз монитор и выигрыша в производительности(ради чего и придумана была эта идея) мы не получим, но при этом второй экземпляр синглтона создать нам таки не получится? то есть код thread-safe, но просто тормозной. Я просто под сломанностью понимал другое до этого.
...
Рейтинг: 0 / 0
31.01.2017, 13:08
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395485
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
no56892
Участник
авторНет, не значит. Это значит, что мы не можем знать, как скоро второй поток увидет изменения переменной в первом потоке.
Но если второй поток это увидел- у нас появляются гарантии.
Это в доках написано черным по белому - то, что запись в volatile автоматически становится видна во всех последующих чтениях. А то, что и все остальное до записи видно - это как side-эффект.

автор
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class Something {
    private static Something instance = null;
    public static Something getInstance() {
        if (instance == null) {
            synchronized (Something.class) {
                if (instance == null)
                    instance = new Something();
            }
        }
        return instance;
    }
    ....
}



В данном случае все ОК, за исключением того, что в случае с volatile некоторые потоки, могли бы увидеть ссылку уже в первой строке, а здесь вынуждены будут заходить в synchronized. Хотя я читал, что без volatile это не работает типо, я так и не увидел никаких доводов - то, что instance не синхронизирована - ну будет null во втором потоке, когда уже в памяти не null, ну зайдем в synchronized и все.
...
Рейтинг: 0 / 0
31.01.2017, 14:14
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395505
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
questioner
Гость
no56892В данном случае все ОК, за исключением того, что в случае с volatile некоторые потоки, могли бы увидеть ссылку уже в первой строке, а здесь вынуждены будут заходить в synchronized. Хотя я читал, что без volatile это не работает типо, я так и не увидел никаких доводов - то, что instance не синхронизирована - ну будет null во втором потоке, когда уже в памяти не null, ну зайдем в synchronized и все.

Вот и у меня такие мысли, то есть синглтон работает, но, вероятно, не эффективно, но прям в каждой статье об этом столько ненависти к этому коду и что мол это "очевидно" не будет работать)

Вот если ссылка не идиножды меняется, то да, тогда очевидно, что будет бяка.
...
Рейтинг: 0 / 0
31.01.2017, 14:34
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395518
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
questioner
Гость
no56892,

хотя вроде как всё-таки нет гарантий, что если мы увидели не null ссылку вне synchronized, то мы увидим все поля, объекта, на который указывает эта ссылка. с другой стороны final вроде гарантирует видимость, а volatile только видимость себя самого гарантирует.


я запутался
...
Рейтинг: 0 / 0
31.01.2017, 14:44
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395525
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
no56892
Участник
questionerno56892,

хотя вроде как всё-таки нет гарантий, что если мы увидели не null ссылку вне synchronized, то мы увидим все поля, объекта, на который указывает эта ссылка.
Допустим, но volatile жеж гарантирует условно только саму себя...
...
Рейтинг: 0 / 0
31.01.2017, 14:52
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395560
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
no56892Это в доках написано черным по белому - то, что запись в volatile автоматически становится видна во всех последующих чтениях.

Цитату, пожалуйста. Где это написано.
...
Рейтинг: 0 / 0
31.01.2017, 15:31
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395564
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
no56892
Участник
Alexey Tomin,

авторA write to a volatile field happens-before every subsequent read of that same field.
https://docs.oracle.com/javase/8/docs/api/
->java.util.concurrent->Memory Consistency Properties
...
Рейтинг: 0 / 0
31.01.2017, 15:34
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395570
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
questionerКстати по поводу DCL и входа в synchronized секцию:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class Something {
    private static Something instance = null;
    public static Something getInstance() {
        if (instance == null) { // point.1
            synchronized (Something.class) {
                if (instance == null)
                    instance = new Something();
            }
        }
        return instance; // point.2
    }
    ....
}


внутри synchronized (Something.class) мы же всегда увидим корректное значение?

Нет.
Поток 1 зашёл, увидел null (в point.1), создал, записал.
Поток в зашёл, увидел не null (в point.1), а вот что он увидет во point.2- вилами на воде писано.
И не надо спрашивать "почему". Ответ всё одно будет- никто не даёт никаких гарантий, что в point.2 будет прочитано непустое значение, даже если в point.1 было именно непустое.
Все "доказатильства" вида "да я миллион раз выполнил и всегда не null" ничего не говорят про то, что через год не выйдет новая прошивка процессора и версия jvm, в которых это ВДРУГ не стрельнёт в одном случае из миллиона.
Современные процессоры очень сложны. Как работают все его оптимизации, спекулятивные ветки и т.п. знает очень мало людей и, поверьте, это не Вы и не я.
Поверх идёт ещё (не самый очевидный) оптимизатор jvm. Который тоже понимают, мягко говоря, не все.
Плюс будущие процессоры (включая принципиально новые архитектуры).
Плюс куча компиляторов (C1, C2, ibm'овский, excelsior graal, ищё чего есть и чего БУДЕТ).

Код надо писать по спецификации. Всё остальное- путь сильного духом и слабого умом.
...
Рейтинг: 0 / 0
31.01.2017, 15:39
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395575
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
no56892Alexey Tomin,

авторA write to a volatile field happens-before every subsequent read of that same field.
https://docs.oracle.com/javase/8/docs/api/
->java.util.concurrent->Memory Consistency Properties

А теперь покажите мне, где "happens-before" переводится как "автоматически становится видна". Это разные термины.
...
Рейтинг: 0 / 0
31.01.2017, 15:42
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395578
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
no56892Alexey Tomin,

авторA write to a volatile field happens-before every subsequent read of that same field.
https://docs.oracle.com/javase/8/docs/api/
->java.util.concurrent->Memory Consistency Properties

Точнее даже так.
Тут написано, что ЕСЛИ случился subsequent read ТО будет happens-before.
...
Рейтинг: 0 / 0
31.01.2017, 15:45
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395587
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
questioner
Гость
Alexey Tomin.
Поток 1 зашёл, увидел null (в point.1), создал, записал.
Поток в зашёл, увидел не null (в point.1), а вот что он увидет во point.2- вилами на воде писано.
И не надо спрашивать "почему". Ответ всё одно будет- никто не даёт никаких гарантий, что в point.2 будет прочитано непустое значение, даже если в point.1 было именно непустое.


Во-первых тыкните пальцем в того, кто Вам в этом топике доказывает таким образом?

Во-вторых я думаю, что если в point.1 мы увидели, что если в point.1 переменная неинициализирована, то и в point.2 она должна быть видна ибо это ведь happens before в рамках одного потока. Но как доказаться правоту чьей-то точки зрения я ума не приложу
...
Рейтинг: 0 / 0
31.01.2017, 15:50
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395591
Common Lisp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Common Lisp
Участник
Alexey TominПоток 1 зашёл, увидел null (в point.1), создал, записал.
Поток в зашёл, увидел не null (в point.1), а вот что он увидет во point.2- вилами на воде писано.Вы хотите сказать, что в point 2 он может опять "увидеть" null?
...
Рейтинг: 0 / 0
31.01.2017, 15:52
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395593
Common Lisp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Common Lisp
Участник
Alexey TominА теперь покажите мне, где "happens-before" переводится как "автоматически становится видна". Это разные термины.А как можно "увидеть", кроме как прочитав?
...
Рейтинг: 0 / 0
31.01.2017, 15:53
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395596
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
questionerAlexey Tomin.
Поток 1 зашёл, увидел null (в point.1), создал, записал.
Поток в зашёл, увидел не null (в point.1), а вот что он увидет во point.2- вилами на воде писано.
И не надо спрашивать "почему". Ответ всё одно будет- никто не даёт никаких гарантий, что в point.2 будет прочитано непустое значение, даже если в point.1 было именно непустое.


Во-первых тыкните пальцем в того, кто Вам в этом топике доказывает таким образом?

У Вас ниже аргументация ещё более зыбкая - "я думаю"

questionerВо-вторых я думаю, что если в point.1 мы увидели, что если в point.1 переменная неинициализирована, то и в point.2 она должна быть видна ибо это ведь happens before в рамках одного потока. Но как доказаться правоту чьей-то точки зрения я ума не приложу

happens before не связывает два ЧТЕНИЯ переменных. Она может связать только ЗАПИСЬ и "последующее" чтение (оно становится последующим, только если есть happens before).
В данном примере ни первое ни второе чтение instance в потоке 2 не связано "happens before" с записью в потоке 1 (для этого надо либо переменную объявить волатильной, либо чтение делать в синхронной сессии). Т.е. оба чтения идут "под гонкой". А значит может случится конфуз.
...
Рейтинг: 0 / 0
31.01.2017, 15:55
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395601
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
no56892
Участник
Alexey Tominno56892Alexey Tomin,

пропущено...

https://docs.oracle.com/javase/8/docs/api/
->java.util.concurrent->Memory Consistency Properties

А теперь покажите мне, где "happens-before" переводится как "автоматически становится видна". Это разные термины.

Вы писали:
авторЭто значит, что мы не можем знать, как скоро второй поток увидет изменения переменной в первом потоке.
Он ее увидит как только прочитает ее, т.е. сразу. А Вы написали, что если увидит запись в волатайл, то типа увидит и все, что было до нее. Т.е. может и не увидеть. Я же говорил о том, что все чтения видят предыдущие записи с volatile. Вот здесь и нужен фактор времени, который Вы отрицали, как мне показалось. Так как два+ потока не могут одновременно писать/читать в одну ячейку памяти, то кто-то из них по времени физически это сделает раньше. Вот что я хотел сказать.
...
Рейтинг: 0 / 0
31.01.2017, 15:58
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395607
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
Common LispAlexey TominПоток 1 зашёл, увидел null (в point.1), создал, записал.
Поток в зашёл, увидел не null (в point.1), а вот что он увидет во point.2- вилами на воде писано.Вы хотите сказать, что в point 2 он может опять "увидеть" null?

Я хочу сказать, что НИГДЕ нет гарантий, что в точке 2 будет снова прочитан не null.

Кстати, на последнем joker'е Шипелёв предложил забавное изменение кода, которое позволяет обойтись без волатильности:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class Something {
    private static Something instance = null;
    public static Something getInstance() {
        Something instance = this.instance; // это позволяет читать под гонкой ровно один раз.
        if (instance == null) {
            synchronized (Something.class) {
                if (this.instance == null)
                    this.instance = new Something();
                else
                    instance = this.instance; // А это чтение h-b, так как синхронизировано.
            }
        }
        return instance;
    }
}



Но я не возьмусь утверждать, что не ошибся. Требуется вдумчивый анализ всех вариантов исполнения двух потоков.

Ну и масса примеров успешных гонок в java.util.concurrent. Только код там- убиться можно.
...
Рейтинг: 0 / 0
31.01.2017, 16:01
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395609
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
no56892Alexey Tominпропущено...


А теперь покажите мне, где "happens-before" переводится как "автоматически становится видна". Это разные термины.

Вы писали:
авторЭто значит, что мы не можем знать, как скоро второй поток увидет изменения переменной в первом потоке.
Он ее увидит как только прочитает ее, т.е. сразу.

Нет такого. В спецификации сказано, что он может прочитать любое более старое значение.
...
Рейтинг: 0 / 0
31.01.2017, 16:02
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395612
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
no56892
Участник
Alexey Tominquestionerпропущено...


Во-первых тыкните пальцем в того, кто Вам в этом топике доказывает таким образом?

У Вас ниже аргументация ещё более зыбкая - "я думаю"

questionerВо-вторых я думаю, что если в point.1 мы увидели, что если в point.1 переменная неинициализирована, то и в point.2 она должна быть видна ибо это ведь happens before в рамках одного потока. Но как доказаться правоту чьей-то точки зрения я ума не приложу

happens before не связывает два ЧТЕНИЯ переменных. Она может связать только ЗАПИСЬ и "последующее" чтение (оно становится последующим, только если есть happens before).
В данном примере ни первое ни второе чтение instance в потоке 2 не связано "happens before" с записью в потоке 1 (для этого надо либо переменную объявить волатильной, либо чтение делать в синхронной сессии). Т.е. оба чтения идут "под гонкой". А значит может случится конфуз.
А какая разница? Допустим синглтон объект вообще без полей (конструктор пустой), т.е. в ссылке может быть ЛИБО null ЛИБО ссылка на готовый объект, при каких обстоятельствах чтение instance будет не null, а return null?
...
Рейтинг: 0 / 0
31.01.2017, 16:03
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395616
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
no56892
Участник
Alexey Tominno56892пропущено...


Вы писали:
пропущено...

Он ее увидит как только прочитает ее, т.е. сразу.

Нет такого. В спецификации сказано, что он может прочитать любое более старое значение.
Цитату плиз)
...
Рейтинг: 0 / 0
31.01.2017, 16:05
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395625
Common Lisp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Common Lisp
Участник
Alexey TominЯ хочу сказать, что НИГДЕ нет гарантий, что в точке 2 будет снова прочитан не null.Что-то мне кажется, что у вас паранойя.

JMM подробно пока не читал, знаком с C++11 memory model, которая выглядит более мозговывернутой, чем JMM. Так вот, если значение в одном потоке может смениться с null на не-null и другой поток увидел не-null, то старое значение — null — он уже никогда не увидит.
...
Рейтинг: 0 / 0
31.01.2017, 16:10
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395626
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
questioner
Гость
Alexey Tomin[

У Вас ниже аргументация ещё более зыбкая - "я думаю"


Вы тоже не приводите обличающих и бесспорных аргументов)


Alexey Tominhappens before не связывает два ЧТЕНИЯ переменных. Она может связать только ЗАПИСЬ и "последующее" чтение (оно становится последующим, только если есть happens before).
В данном примере ни первое ни второе чтение instance в потоке 2 не связано "happens before" с записью в потоке 1 (для этого надо либо переменную объявить волатильной, либо чтение делать в синхронной сессии). Т.е. оба чтения идут "под гонкой". А значит может случится конфуз.

Ну вот хотелось бы прув на это, я не говорю, что это не так, просто я нигде такого не видел среди прочитанного.
...
Рейтинг: 0 / 0
31.01.2017, 16:10
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395630
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
questioner
Гость
Alexey TominCommon Lispпропущено...
Вы хотите сказать, что в point 2 он может опять "увидеть" null?

Я хочу сказать, что НИГДЕ нет гарантий, что в точке 2 будет снова прочитан не null.

Кстати, на последнем joker'е Шипелёв предложил забавное изменение кода, которое позволяет обойтись без волатильности:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class Something {
    private static Something instance = null;
    public static Something getInstance() {
        Something instance = this.instance; // это позволяет читать под гонкой ровно один раз.
        if (instance == null) {
            synchronized (Something.class) {
                if (this.instance == null)
                    this.instance = new Something();
                else
                    instance = this.instance; // А это чтение h-b, так как синхронизировано.
            }
        }
        return instance;
    }
}



Но я не возьмусь утверждать, что не ошибся. Требуется вдумчивый анализ всех вариантов исполнения двух потоков.

Ну и масса примеров успешных гонок в java.util.concurrent. Только код там- убиться можно.

а в чем разница? какое здесь h-b появляется дополнительно?
...
Рейтинг: 0 / 0
31.01.2017, 16:15
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395639
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
no56892Это в доках написано черным по белому - то, что запись в volatile автоматически становится видна во всех последующих чтениях.Во всех доках пишется, что чтения из volatile не оптимизируются (путём кэширования в регистрах), а всегда делаются обращением к памяти, а это несколько другое.
...
Рейтинг: 0 / 0
31.01.2017, 16:22
| Ответить | Цитировать | Написать  
syncronized vs volatile с точки зрения visibility
    #39395645
Фотография Usman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Usman
Участник
questionersyncronized vs volatile с точки зрения visibility synchronized и volatile - работают в неразрывной связке. Visibility обеспечивается за счет volatile . (точка)
...
Рейтинг: 0 / 0
31.01.2017, 16:28
| Ответить | Цитировать | Написать  
25 сообщений из 135, страница 3 из 6
  3  все
Форумы / Java [игнор отключен] [закрыт для гостей] / syncronized vs volatile с точки зрения visibility
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=39395625&tid=2123178]:
 0ms
get settings:
 11ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 5ms
track hit:
 65ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 72ms
get tp. blocked users:
 1ms
others: 242ms
total:  427ms
созд. / загр.: 427ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]