|
|
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
Помогите разобраться с ReentrantReadWriteLock javaDocFair mode .... 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. A thread that tries to acquire a fair write lock (non-reentrantly) will block unless both the read lock and write lock are free (which implies there are no waiting threads). (Note that the non-blocking ReentrantReadWriteLock.ReadLock.tryLock() and ReentrantReadWriteLock.WriteLock.tryLock() methods do not honor this fair setting and will acquire the lock if it is possible, regardless of waiting threads.) Я что-то не до конца понял в чём разница для захвата read и write лока ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 16:11 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
Если захватил read, то все остальные потоки тоже могут захватить read ещё до его освобождения первым потоком (но write захватить не сможет никто, пока все read не отпустят). Если захватил write, то никто другой уже ничего захватить не сможет (работает идентично synchronized секции) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 16:28 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
For All, это то я понимаю.... а всё в фэйр моде делается по очереди? ну скажем делается поток1 запись1: 0----------------------100 поток2 момент времени 10: приходит запрос на захват чтения поток3 момент времени 20: приходит запрос на захват чтения поток4 момент времени 30: приходит запрос на захват чтения поток5 момент времени 40: приходит запрос на захват записи поток6 момент времени 50: приходит запрос на захват чтения поток7 момент времени 60: приходит запрос на захват записи поток8 момент времени 70: приходит запрос на захват записи поток9 момент времени 80: приходит запрос на захват чтения то все потоки в таком порядке и выполнятся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 16:45 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
Если я правильно понял, то 1й поток сначала захватил write на период [0..100]. Пока write захвачен, все остальные запросы висят в ожидании. Как только write отпущен (в момент 100), то дальше дело случая: кто-то из ожидающих первый схватит освободившийся lock. Если это снова write, то повторяется то что я только что описал: все остальные опять ждут пока write не будет отпущен. Если это read, то все потоки, которые ожидают чтобы захватить read, его тут же захватят (т.е. ломанётся толпа). Пока read захвачен все новые запросы на read беспрепятственно блокируются, а запросы на write подвисают в ожидании. Как только все read буду освобождены (каждым из толпы) мы снова приходим к ситуации когда lock свободен (но тут уже в ожидании висят только те, кто запрашивал write - соответствнно следующий захват будет типа write) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 17:38 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
For AllЕсли я правильно понял, то 1й поток сначала захватил write на период [0..100]. Пока write захвачен, все остальные запросы висят в ожидании. Как только write отпущен (в момент 100), то дальше дело случая: кто-то из ожидающих первый схватит освободившийся lock. Если это снова write, то повторяется то что я только что описал: все остальные опять ждут пока write не будет отпущен. Если это read, то все потоки, которые ожидают чтобы захватить read, его тут же захватят (т.е. ломанётся толпа). Пока read захвачен все новые запросы на read беспрепятственно блокируются, а запросы на write подвисают в ожидании. Как только все read буду освобождены (каждым из толпы) мы снова приходим к ситуации когда lock свободен (но тут уже в ожидании висят только те, кто запрашивал write - соответствнно следующий захват будет типа write) Вы про non-fair режим говорите, а ТС спрашивает именно про fair. И ответом будет да, вы правильно поняли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 18:28 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
For All, For AllКак только write отпущен (в момент 100), то дальше дело случая: кто-то из ожидающих первый схватит освободившийся lock. в fair моде точно нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 18:32 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
redwhite90, Да, в fair моде это дело уже не случая - кто первый постучался, тот первый и получит lock после освобождения. Соответсвенно, те 8 ждущих потоков будут выполняться последовательно (при этом те, которые хотят read, будут объединены в группы) А есть ли смысл при написании многопоточных программ рассчитывать на наличие fair мода? Как по мне проще о нём не вспоминать даже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 19:14 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
For All, For AllСоответсвенно, те 8 ждущих потоков будут выполняться последовательно (при этом те, которые хотят read, будут объединены в группы) что значит объединены в группы? просто одновременно(с определенной погрешностью) ведь начнут выполняться только те read потоками, что между двумя write потоками? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 21:40 |
|
||
|
ReentrantReadWriteLock. Чем отличается захват read и write лока?
|
|||
|---|---|---|---|
|
#18+
redwhite90For All, For AllСоответсвенно, те 8 ждущих потоков будут выполняться последовательно (при этом те, которые хотят read, будут объединены в группы) что значит объединены в группы? просто одновременно(с определенной погрешностью) ведь начнут выполняться только те read потоками, что между двумя write потоками? Да имеено это я имел ввиду: read потоки (те которые между write) начнут работу одновременно, а не так что первый начнёт-закончит, после второй начнёт-закончит и т.д. Т.е. получается группа одновременно работающих read потоков. А вот write поток уже только один будет работать, и все остальные (и read-ы, и write-ы) будут ждать окончания его работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 12:04 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38616847&tid=2127326]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
174ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 540ms |

| 0 / 0 |
