|
|
|
Изучение многопоточности в Java
|
|||
|---|---|---|---|
|
#18+
no56892, Это не работает т.к. while(!flag) {} тупо не перечитывает из памяти (куда дб попасть т.к. final в конструкторе). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 23:00 |
|
||
|
Изучение многопоточности в Java
|
|||
|---|---|---|---|
|
#18+
questionerКстати предлагаю разобрать, кто чувствует силы в себе, по полочкам пример кода: ... Ожидаю, что сейчас посоветуют читать Concurrency in practise. Но для начала это слишком суровое чтиво. Нет не посоветую. Вместо этого вот вам всем неуверенным в себе первое, что вы должны знать о многопоточности: информация между потоками не передается через голые переменные, как реализовано в приведенном вами примере. Необходимо использовать связующий объект. В 90% подойдет любая реализация интерфейса BlockingQueue. Производитель вызывает метод put(), а потребитель - метод take(). В вашем примере, когда надо передать только одно значение, лучшим вариантом будет какая-либо реализация интерфейса Future, например CompletableFuture, так как дает возможность передать не только значение при удачном исходе, но и исключение при неудачном. Второе: прочитайте бегло документацию, чтобы знать, какие связующие объекты уже реализованы. Это почти все, что нужно знать рядовому программисту о многопоточности. Третье: Concurrency in practiсe и все прочие книги, которые описывают, как использовать synchronized/wait/notify/ReentrantLock нужны только затем, чтобы реализовать специфический связующий объект в случае, если существующие реализации чем-то не устраивают. И прежде чем читать такие книги, лучшая учеба - читать исходники уже реализованных связующих объектов. Причем исходники java.util.concurrent - не лучший источник вдохновения: они вылизаны с точки зрения производительности, но авторы принесли в жертву понятность и убедительность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 01:37 |
|
||
|
Изучение многопоточности в Java
|
|||
|---|---|---|---|
|
#18+
questionerНу и кстати, господа, насчёт практики, кто нить может таки про код то пояснить? Если код будет сразу нативным. Не будет вызова GC, перелета потока с одного проца на другой и пр. неожиданных событий по сбросу кеша, то побудительных причин , для того, чтоб instance стал отличным от null в основном потоке, вроде бы и может не оказаться. questionerНО, судя по всему, подразумевается, что условием видимости будет то, что чтение произошло после записи. Оно самое, а в дополнение JMM требует от JVM, чтобы та обеспечила видимость и всего остального, что было до того, раз это действие видимо. P.S. System.out.print хреновое средство для твоей задачи - оно само неявно ставит барьеры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 09:50 |
|
||
|
Изучение многопоточности в Java
|
|||
|---|---|---|---|
|
#18+
no56892Т.е. это по факту так, но в JMM не гарантируется, вывод - final поля видны после инициализации, а также видны все действия с final полями в конструкторе если строго по JMM и не залипать на текущее положение дел. Вроде все :). Немного уточню, процитировав комент, на который ссылается Алексей jdk // 1. The constructor wrote a final. The effects of all initializations // must be committed to memory before any code after the constructor // publishes the reference to the newly constructed object. Rather // than wait for the publication, we simply block the writes here. // Rather than put a barrier on only those writes which are required // to complete, we force all writes to complete. JMM требует создать барьер в момент когда инициализированы все final поля. Поскольку разбивать конструктор сильно влом, да и чревато, авторы OpenJDK несколько ужесточают подход создают его по окончании конструктора в данном случае. В принципе на других JVM (и в отдаленном будущем) это может быть и не так, но маловероятно ибо "А зачем?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 10:11 |
|
||
|
Изучение многопоточности в Java
|
|||
|---|---|---|---|
|
#18+
rfqВ 90% подойдет любая реализация интерфейса BlockingQueue. Производитель вызывает метод put(), а потребитель - метод take(). Хотелось бы посмотреть на реализацию Singletone через BlockingQueue, метод put() и метод take(). Начиная с безопасной публикации самого BlockingQueue таким образом, а не через голое final поле или еще как-нибудь так. Да и выстраивание потоков в очередь это порой приводит к "многопоточности", которая медленнее одного потока. P.S. Многопоточность IMHO следует начинать с осознания того, что она нужна только когда можно потоки развести между собой и как это делается. И почему обмен информацией между ними это всегда проблемка. А потом уж выбирать способ который эту проблемку решит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 10:23 |
|
||
|
Изучение многопоточности в Java
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевquestionerНу и кстати, господа, насчёт практики, кто нить может таки про код то пояснить? Если код будет сразу нативным. Не будет вызова GC, перелета потока с одного проца на другой и пр. неожиданных событий по сбросу кеша, то побудительных причин , для того, чтоб instance стал отличным от null в основном потоке, вроде бы и может не оказаться. то есть точно вы не уверены? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 11:00 |
|
||
|
Изучение многопоточности в Java
|
|||
|---|---|---|---|
|
#18+
questioner, Так речь то про то, что гарантий нет, как в одну, так и в другую сторону (может увидит изменение, а может и нет). Ошибки в парралельной работе иногда выражаются в том, что код работает и на тестах и в жизни. А потом кто-то находит способ устроить гонку и списать деньги не со своего счета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 11:11 |
|
||
|
|
start [/forum/topic.php?fid=59&msg=39397062&tid=2123187]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
56ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
| others: | 250ms |
| total: | 411ms |
| 0 / 0 |
