|
|
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
Собственно пример из книжки: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. и мы хотим научиться стопать эту машину. Тут у нас много продюсеров и всего один consumer. Дальше идёт предложение сделать флаг, который будет прекращать добавление новых сообщений в очередь и приводится вот такой вот код: Код: java 1. 2. 3. 4. 5. 6. и такой вот текст: авторAnother approach to shutting down LogWriter would be to set a “shutdown requested” flag to prevent further messages from being submitted, as shown in Listing 7.14. The con- sumer could then drain the queue upon being notified that shutdown has been requested, writing out any pending messages and unblocking any producers blocked in log . However, this approach has race conditions that make it unreliable. The implementation of log is a check-then-act sequence: producers could observe that the service has not yet been shut down but still queue messages after the shutdown, again with the risk that the producer might get blocked in log and never become unblocked. There are tricks that reduce the likelihood of this (like having the consumer wait several seconds before declaring the queue drained), but these do not change the fundamental problem, merely the likelihood that it will cause a fail- ure. Я не понял почему там race condition. В чем проблема я тоже не понял. А также хотелось бы понять продюсеры могут залочиться? P.S. Чего-то тут совсем никак не перевести автор producers could observe that the service has not yet been shut down but still queue messages after the shutdown, again with the risk that the producer might get blocked in log and never become unblocked. Продюсеры могут наблюдать, что сервис, который ещё не выключен до сих пор набирает сообщения в очередь(wtf?), вновь есть риск, что продюссер может залочиться и никогда не разлочиться. Ничего не понял из этого предложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 02:25 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
questioner, race condition может быть такой: Код: java 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 03:46 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
questionerЧего-то тут совсем никак не перевести автор producers could observe that the service has not yet been shut down but still queue messages after the shutdown, again with the risk that the producer might get blocked in log and never become unblocked. Продюсеры могут наблюдать, что сервис, который ещё не выключен до сих пор набирает сообщения в очередь(wtf?), вновь есть риск, что продюссер может залочиться и никогда не разлочиться. Ничего не понял из этого предложения. Продьюсеры могут видеть, что сервис еще не выключен, но при этом все равно получится так, что они добавят сообщения в очередь, когда он таки уже будет выключен. Залочиться же продьюсеры могут, насколько я понимаю, в случае, если logger thread завершился, а очередь при этом уже успели забить новыми сообщениями, через race condition, не зная о том, что shutdown requested. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 03:53 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
base2questioner, race condition может быть такой: Код: java 1. 2. 3. 4. 5. 6. Согласен, что это race condition. В принципе может быть, что между этими двумя строками LoggerThread проверит, что в очереди ничего нет и флаг включен и можно вырубаться в таком случае, а на самом деле сообщения ещё есть а по поводу того почему продюсеры блокируются не понял. queue.put неблокирующий метод. Он блокируется только в том случае, если очередь переполнена. ведь LoggerThread в одном потоке разгребает очередь, разве такое возможно, что он успеет разгрести всю очередь до того, как потоки разблокируются и вставят новое значение в очередь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 10:11 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
В дополнение ещё по этой теме хотел бы понять почему автор выбрал правильное решение такое: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. Тут 3 синхронайзд блока и ещё добавлен каунтер reservations такой вариант будет небезопасным или может будет работать медленнее? Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 13:25 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
questionerтакой вариант будет небезопасным или может будет работать медленнее? Код: java 1. 2. 3. 4. 5. Код: java 1. 2. 3. 4. 5. Так что на добавлении 1001 msg возможен deadlock ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 13:56 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньевquestionerтакой вариант будет небезопасным или может будет работать медленнее? Код: java 1. 2. 3. 4. 5. Код: java 1. 2. 3. 4. 5. Так что на добавлении 1001 msg возможен deadlock Не понял. Два потока понятно какие. а где 2 ресурса? и где они захватываются в разном порядке? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 15:02 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
хотя понял, видимо требование про порядок - необязательное. просто как вариант дедлока ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 15:07 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
questioner, очередь и монитор. Внутри монитора писатель в очередь будет ждать при переполнении ее разгребания, а разгребатель будет ждать монитора. Или я что-то не так понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 15:11 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
questionerа по поводу того почему продюсеры блокируются не понял. queue.put неблокирующий метод. Он блокируется только в том случае, если очередь переполнена. ведь LoggerThread в одном потоке разгребает очередь, разве такое возможно, что он успеет разгрести всю очередь до того, как потоки разблокируются и вставят новое значение в очередь? В общем случае у тебя очередь не обязательно из 1000 элементов. Предположим, что она ограничена двумя и представим ситуацию, когда очередь в данный момент пуста и мы выставляем shutdownRequested в true. LoggerThread успевает это увидеть, проверяет, что очередь пуста и завершается. В то же время, скажем, 3 producer-треда попадают на put через гонку - 2 из них положат свои значения в очередь, а третий заблокируется навсегда, так как освобождать очередь уже некому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 18:59 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. Кстати, этот код не совсем будет корректно работать, если дойдет до макс размера (ну или через конструктор указать размер фиксированный очереди). Если reservations будет не 0, а очередь пуста, то сколько бы не вызывать shutdown() он не сработет. А может это быть в таком случае: фикс размер очереди, например 1, два потока добавляют 2 элемента, теперь reservations == 2, далее один из них интерраптится на put(), в результате в очереди по факту 1 элемент, а reservations == 2. Теперь shutdown() не сработает никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 19:20 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньевquestioner, очередь и монитор. Внутри монитора писатель в очередь будет ждать при переполнении ее разгребания, а разгребатель будет ждать монитора. Или я что-то не так понял? Не, всё верно. Я почему-то думал, что дедлок это обязательно захват мониторов в разных порядках. а тут у нас для того, чтобы добавить/освободить очередь нужно 1. захватить монитор 2. дождаться пока блокирующий метод исполнится. и собственно если монитор занят тредом, который не может добавить, то тред который разгребает ничего не сможет сделать) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 19:40 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
base2questionerа по поводу того почему продюсеры блокируются не понял. queue.put неблокирующий метод. Он блокируется только в том случае, если очередь переполнена. ведь LoggerThread в одном потоке разгребает очередь, разве такое возможно, что он успеет разгрести всю очередь до того, как потоки разблокируются и вставят новое значение в очередь? В общем случае у тебя очередь не обязательно из 1000 элементов. Предположим, что она ограничена двумя и представим ситуацию, когда очередь в данный момент пуста и мы выставляем shutdownRequested в true. LoggerThread успевает это увидеть, проверяет, что очередь пуста и завершается. В то же время, скажем, 3 producer-треда попадают на put через гонку - 2 из них положат свои значения в очередь, а третий заблокируется навсегда, так как освобождать очередь уже некому. ага, понятно, спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 19:52 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
Усовершенствованная версия, без мьютексов. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2017, 20:31 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
no56892, Код: java 1. получается, что мы так и без остановки явной можем остановиться. Стоит только в какой-то момент очереди опустеть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2017, 11:16 |
|
||
|
LogWrite пример из Concurrency in practice. Где тут race condition?
|
|||
|---|---|---|---|
|
#18+
|| и && не путаешь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2017, 17:15 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=39408736&tid=2123122]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
90ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
| others: | 230ms |
| total: | 452ms |

| 0 / 0 |
