|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
Коллеги, Happens-before - очень простая идея для тех, кто ее уже вкурил. Но как ее вменяемо объяснить новичкам? В документации и туториалах Java объяснено плохо, в Java Concurrency in Practice тоже. Все не то. Я пытался сформулировать мое понимание этого как можно более понятно, и в итоге пришел к такому определению. Если: 1) Поток A изменил состояние системы S (write), 2) поток B заметил это изменение (read), 3) и операции изменения и чтения состояния S связаны соотношением happens-before, то все последующие операции потока B увидят все изменения, совершенные потоком A до изменения состояния S. На мой взгляд, это корректное, годное определение. Если подкрепить его картинками и парочкой примером, то слушатель все поймет. НО!!! 1) Согласны ли вы с тем, что это утверждение корректно? Ведь по сути здесь я ставлю знак равенства между happens-before и acquire/release семантикой. Правомерно ли это? Можно ли, например, утверждать, что happens-before на Thread.interrupt -> Thread.isInterrupted или Thread.start() -> тело Runnable() имеют acquire/release семантику? Вот что-то у меня здесь сомнения есть. Боюсь, надо будет в concurrency interest писать на эту тему. 2) Оно мне кажется слишком громоздким. Как его упростить? В принципе, неплохо написано вот здесь http://preshing.com/20130702/the-happens-before-relation (всем рекомендую забукмаркать этот интереснейший бложег), но немного неполно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.08.2013, 20:54 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
Вы немного себе противоречите, сначала спрашиваете как проще всего обьяснить новичкам, а потом спрашиваете о тонкостях точного и корректного описания. Нужна точность и хитрости - значит обьяснение формально. Нужно быстрое понимание в общем - значит неформально на пальцах донести идею, а потом переходить к тонкостям. Где-то видел такой пример в виде слайдов - 1) Потоки устроены хитро, запись и чтение переменной в одном потоке не гарантирует правильный и мгновенный результат в другом потоке 2) Нужны гарантии 3) гарантии предоставляются Java Memory Model 4) Посредством соглашений и расставления некоторых инструкций в определенных точках программы, все это называется happens-before 5) список 6) тонкости Конечно я уже имел понятие о хэппенс-бефоре но мне понравилось, стиль не авторский, а в моем пересказе. Как по мне ваши вариант автор1) Поток A изменил состояние системы S (write), 2) поток B заметил это изменение (read), 3) и операции изменения и чтения состояния S связаны соотношением happens-before, Сбивает с толку - такое ощущение что потоки сами что-то делают как-то синхронизируются, а вся соль в том что программист должен управлять кодом и расставлять happens-before. Все написанное сугубо мое имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.08.2013, 21:21 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
DEVcoachто все последующие операции потока B увидят все изменения, совершенные потоком A до изменения состояния S. 1) Согласны ли вы с тем, что это утверждение корректно? Вот эта часть некорректна. Там все сложнее. В целом JVM говорит даже не о том, какие записи будут видны, а о том, какие записи будут не видны. В случае корректно синхронизированных программ ваше определение более-менее корректно. Но вот в случае некорректно синхронизированных потоков может вводить в заблуждение. DEVcoachВедь по сути здесь я ставлю знак равенства между happens-before и acquire/release семантикой. Правомерно ли это? Можно ли, например, утверждать, что happens-before на Thread.interrupt -> Thread.isInterrupted или Thread.start() -> тело Runnable() имеют acquire/release семантику? Вот что-то у меня здесь сомнения есть. Боюсь, надо будет в concurrency interest писать на эту тему. Оно похоже на acquire/release. Но вот "количество" не сохраняется в отличие честных семафоров. Один volatile write может happens-before нескольких volatile read. А еще оно на Lamport timestamps очень похоже. DEVcoach2) Оно мне кажется слишком громоздким. Как его упростить? А смысл? Новичкам важнее донести мысль о том, что программа должна быть "корректно синхронизирована". В этом случае на программе вроде бы появляется total order, причем согласованный с порядком инструкций в каждом потоке. А в некорректно синхронизированной программе еще и causality requirement важен. По сравнению с ним любое объяснение happens-before - мелочи. P.S. здесь я писал (Maxim Karvonen) примерно о том же (оно вроде бы еще и causality requirement неплохо покрывает). Это как раз lamport timestamps. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2013, 09:39 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
ААА! Все, я нашел доказательство! Читаем главы 17.4.4 и 17.4.5 ! То есть, 1) synchronized-with это как раз таки acquire-release семантика, которая действует при: - acquire/release монитора - volatile read/write - thread.start()/первая команда в новом треде - последняя команда в треде / thread.join()-thread.isAlive() 2) А happens-before это видимость одного конкретного изменения между тредами, которая возникает: - Всегда в рамках одного треда - финиш конструктора - вход в finalize() - все synchronized-with сценарии Ну пипец, и как теперь вот это вот объяснять людям? Помозгую я конечно над простым объяснением, но чую таки придется делать ставку на объяснение "на пальцах". Плюс визуальный ряд должен сильно помочь. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2013, 09:40 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
DEVcoach, на ютубе глянье конференции. Там были в том числе нормальные обьяснения, с нормальными понятными слайдами. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2013, 11:16 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
Вход/выход в синхронайзд блок - это happen-before. Чтение/запись volatile-переменной тоже. Вопрос, если чтение/запись volatile переменной всеми потоками происходит внутри синхронайзд блока, то ключевое слово volaitle для этой переменной можно не использовать? В коде ниже нужно указыввать volatile? Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2020, 09:29 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
1) не нужно обьявлять volatile 2) лучше использовать notifyAll ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2020, 12:44 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2020, 12:55 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
мне вот интересно а где все это напрямую используется? я уже хренову тонну реальных проектов перелопатил все что я встречал это ComletableFeature мб у нее там под капотом эта вся шляпа лежит) но тоесть вот явно чтобы кто то там лочил ,семафорил и тд - я не видел ни разу ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2020, 22:26 |
|
Лучший способ объяснить happens-before
|
|||
---|---|---|---|
#18+
Они говорят о самых low-level примитивах синхронизации на базе которых строятся боле высокоуровневые. SimpleLockImplementation - это иммитиация стандартного Lock на примитивах. Похоже на тестовое задание. В проде щас никто так не делает ибо нет смысла. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2020, 10:06 |
|
|
start [/forum/topic.php?fid=59&msg=38368656&tid=2120757]: |
0ms |
get settings: |
25ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
258ms |
get tp. blocked users: |
1ms |
others: | 309ms |
total: | 664ms |
0 / 0 |