|
|
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
1. Поток 1 вставляет данные в сегмент_1(это операция занимает какое-то время) 2. Поток 2 хочет прочитать данные из сегмента_1 в момент времени 2(когда поток 1 один ещё не завершил put) 3. Поток 3 пытается вставить данные в сегмент_1 в момент времени 3(когда поток 1 один ещё не завершил put) Кто победит? поток 2 или поток 3 ? и похожий вопрос про ReentrantReadWriteLock Пока сидим в read локе прилетело 2 запроса на read и write. Кто победит? 1. Не fair 2. Fair. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2017, 18:03 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
По поводу мапы выяснил, что там мутабельная и не мутабельная операция на одном сегменте может исполняться в параллель. Это сюрприз. А по поводу ReadWriteLock - неясно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 11:01 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
по поводу ReentrantReadWriteLock переформулирую Если во время чтения в не-fair моде прилетело ещё 2 запроса. Один из которых на чтение, а другой на запись, то будет ли преимущество у того, который на чтение по той причине, что чтение уже идёт ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 11:20 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
questioner, стесняюсь спросить, а вам в лом посмотреть исходники сдк? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 11:49 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
А мне практический смысл вопроса не очень понятен. Если практически становятся такие вещи важны - это же какая конкуренция должна быть? Честно говоря, мне такое даже не представить. Точнее не представить, как при такой конкуренции система работает, а не "стоит колом". AFAIK Если конкуренция настолько зашкаливает, хорошо бы еще убедится, что дело именно в Java-коде, а например не в планировщике ОС и/или параметрах java машины. Ну и опять таки, существует 100500 альтернативных реализаций конкурентных коллекций. Выбирай не хочу. На Oracle/Sun реализации все клином не сошлось. Да и выбор в стандартной Java не сильно уж и богатый (точнее выбора вообще нет) IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 14:44 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
twr143questioner, стесняюсь спросить, а вам в лом посмотреть исходники сдк? Они не настолько очевидно написаны. Но если Вы в состоянии, то я буду рад услышать ваше мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 15:56 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevА мне практический смысл вопроса не очень понятен. Если практически становятся такие вещи важны - это же какая конкуренция должна быть? Честно говоря, мне такое даже не представить. Точнее не представить, как при такой конкуренции система работает, а не "стоит колом". AFAIK Если конкуренция настолько зашкаливает, хорошо бы еще убедится, что дело именно в Java-коде, а например не в планировщике ОС и/или параметрах java машины. Ну и опять таки, существует 100500 альтернативных реализаций конкурентных коллекций. Выбирай не хочу. На Oracle/Sun реализации все клином не сошлось. Да и выбор в стандартной Java не сильно уж и богатый (точнее выбора вообще нет) IMHO & AFAIK На собеседовании спросили. В целом неплохо иметь понимание как работает инструмент с которым приходится работать. Ну и выбор инструмента зависит от понимания того как он работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 15:58 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
questioner, ConcurrentHashMap (8): Код: 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. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. в методе putVal синхронизация идёт по первой ноде сегмента, синхронизация интринсик, автоматически unfair. get: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Здесь блокировка отсутствует в принципе. Вывод: put и get независимы, операции put в каждый сегмент последовательны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 19:15 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
questioner, ReadWriteLock. ReadLock - попытка захвата: первый пункт в комменте говорит что read ждёт write, первый if это имплементит. Код: 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. WriteLock: попытка захвата: первый коммент говорит что write ждёт все залоченные риды и залоченный write. Код, следующий за // (Note: if c != 0 and w == 0 then shared count != 0) это имплементит Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 20:11 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
twr143ReadWriteLock. ReadLock - попытка захвата: первый пункт в комменте говорит что read ждёт write, первый if это имплементит. автор1. If write lock held by another thread, fail. Только если этот writeLock уже захвачен. Про конкуренцию за лок ничего не написано twr143WriteLock: попытка захвата: первый коммент говорит что write ждёт все залоченные риды и залоченный write. Код, следующий за // (Note: if c != 0 and w == 0 then shared count != 0) это имплементит авторIf read count nonzero or write count nonzero and owner is a different thread, fail. Аналогично. Меня беспокоит вариант, что если read lock никогда не отпускается, то это значит, что writeLock не имеет даже теоретических шансов захватиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 23:41 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
questioner, в методе readerShouldBlock , вызывающемся из tryAcquireShared и writerShouldBlock из tryAcquire описаны стратегии дополнительной фильтрации для FairSync и NonfairSync. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 07:44 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
twr143questioner, в методе readerShouldBlock , вызывающемся из tryAcquireShared и writerShouldBlock из tryAcquire описаны стратегии дополнительной фильтрации для FairSync и NonfairSync. Ну как-то там не много написано. Код: java 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 10:53 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
questionertwr143questioner, в методе readerShouldBlock , вызывающемся из tryAcquireShared и writerShouldBlock из tryAcquire описаны стратегии дополнительной фильтрации для FairSync и NonfairSync. Ну как-то там не много написано. Код: java 1. 2. 3. 4. 5. 6. 7. сий код вам говорит, что ридер в режиме unfair c радостью пропустит первый поток в очереди, если он writer. У ноды head потока нет, в чём вы можете убедиться, изучив метод setHead. Поэтому первый поток в очереди хранит нода h.next ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 12:22 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
twr143questionerпропущено... Ну как-то там не много написано. Код: java 1. 2. 3. 4. 5. 6. 7. сий код вам говорит, что ридер в режиме unfair c радостью пропустит первый поток в очереди, если он writer. У ноды head потока нет, в чём вы можете убедиться, изучив метод setHead. Поэтому первый поток в очереди хранит нода h.next А как вы по этому отрывку это поняли? Это список чего хоть? Вот в JCIP нашёл: авторInternally, AQS maintains a queue of waiting threads, keeping track of whether a thread has requested exclusive or shared access. In ReentrantRead-WriteLock, when the lock becomes available, if the thread at the head of the queue was looking for write access it will get it, and if the thread at the head of the queue was looking for read access, all queued threads up to the first writer will get it.[15] [15] This mechanism does not permit the choice of a readerͲpreference or writerͲpreference policy, as some readͲwrite lock implementations do. For that, either the AQS wait queue would need to be something other than a FIFO queue, or two queues would be needed. However, such a strict ordering policy is rarely needed in practice; if the nonfair version of ReentrantReadWriteLock does not offer acceptable liveness, the fair version usually provides satisfactory ordering and guarantees nonstarvation of readers and writers То есть получается, что ридеры не могу обгонять врайтеров и, видимо, наоборот, тоже. Но это как-то уж сильно напоминает fair policy. Или разница fair мода только в том, что внутри группы ридеров/врайтеров порядок гарантированный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 16:44 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
twr143, авторсий код вам говорит, что ридер в режиме unfair c радостью пропустит первый поток в очереди, если он writer. Откуда вообще очередь в unfair mode ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 16:45 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
fair: JDK * <dt><b><i>Fair mode</i></b> * <dd>When constructed as fair, threads contend for entry using an * approximately arrival-order policy. When the currently held lock * is released, either the longest-waiting single writer thread will * be assigned the write lock, or if there is a group of reader threads * waiting longer than all waiting writer threads, that group will be * assigned the read lock. * * <p>A thread that tries to acquire a fair read lock (non-reentrantly) * will block if either the write lock is held, or there is a waiting * writer thread. The thread will not acquire the read lock until * after the oldest currently waiting writer thread has acquired and * released the write lock. Of course, if a waiting writer abandons * its wait, leaving one or more reader threads as the longest waiters * in the queue with the write lock free, then those readers will be * assigned the read lock. * В первом потоке пишут, что может захватить как writer, так и группа reader-ов, которая ждёт дольше самого древнего write-а, а во втором, что read не сможет захватить лок до тех пор пока есть write который ждёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 17:01 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
авторВ первом потоке абзаце* ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 17:01 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
questionerfair: JDK * <dt><b><i>Fair mode</i></b> * <dd>When constructed as fair, threads contend for entry using an * approximately arrival-order policy. When the currently held lock * is released, either the longest-waiting single writer thread will * be assigned the write lock, or if there is a group of reader threads * waiting longer than all waiting writer threads, that group will be * assigned the read lock. * * <p>A thread that tries to acquire a fair read lock (non-reentrantly) * will block if either the write lock is held, or there is a waiting * writer thread. The thread will not acquire the read lock until * after the oldest currently waiting writer thread has acquired and * released the write lock. Of course, if a waiting writer abandons * its wait, leaving one or more reader threads as the longest waiters * in the queue with the write lock free, then those readers will be * assigned the read lock. * В первом потоке пишут, что может захватить как writer, так и группа reader-ов, которая ждёт дольше самого древнего write-а, а во втором, что read не сможет захватить лок до тех пор пока есть write который ждёт. Чтобы не задавать такие вопросы я и вставил вам код tryAcquireShared и tryAcquirу. В первой части этих методов реквест фильтруется на основе уже фактически захваченных локов. Во второй части (writerShouldBlock() и readShouldBlock()) локи свободны и возможная фильтрация идёт на основе порядка других потоков в очереди ожидания! Ваш вопрос про первую часть, а я вам уже объясняю вторую ! Не смешивайте апельсины и яблоки! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 17:17 |
|
||
|
fairness of ConcurentHashMap
|
|||
|---|---|---|---|
|
#18+
Offtopic questionerВ целом неплохо иметь понимание как работает инструмент с которым приходится работать. Хорошо понимать из какого корпуса сделан микроскоп, что бы знать, через сколько ударов по гвоздю он сломается. А перед пользованием молотком, хорошо бы прочитать учебник по сопротивлению материалов. questionerНу и выбор инструмента зависит от понимания того как он работает. Выбор инструмента зависит от ЗАДАЧИ которую приходится решать. Понимание того, как он работает - обычно требуется тогда, когда инструмент сломался и его приходится чинить. Более часто встречающаяся ситуация, когда реклама (документация и т.д.) для инструментов почти полностью НЕ соответствует действительности. Тогда хорошо бы хоть примерно понимать из чего оно сделано. Иначе результат может быть как от патентованной краски, которой Киса Воробьянинов голову покрасил (12 стульев). IMHO & AFAIK questionerНа собеседовании спросили. Мне кажется, что если кто-то бы напрягся и написал сборник "вопросы на собеседовании", то он имел бы успех не меньший, чем всемирно известные "армейские маразмы". questionerЕсли во время .... IMHO ответ на данный вопрос находится... в документации В документации этого нет? Значит, как бы класс реально не работал, это undocumented поведение и закладываться на него при написании реальной системы НЕЛЬЗЯ. В целом, можно повторить слова, которым более 2000 лет: "От многих знаний, много печалей. Поэтому тот, кто приумножает знания, приумножает скорбь" Пожалейте этот мир. Не делайте его еще хуже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 20:24 |
|
||
|
|

start [/forum/topic.php?fid=59&fpage=72&tid=2123071]: |
0ms |
get settings: |
12ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 377ms |

| 0 / 0 |
