Re: Wait free LW_SHARED acquisition - v0.2
От | Andres Freund |
---|---|
Тема | Re: Wait free LW_SHARED acquisition - v0.2 |
Дата | |
Msg-id | 20141008130013.GB11524@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Wait free LW_SHARED acquisition - v0.2 (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On 2014-10-08 14:47:44 +0200, Andres Freund wrote: > On 2014-06-25 19:06:32 +0530, Amit Kapila wrote: > > 5. > > LWLockWakeup() > > { > > .. > > dlist_foreach_modify(iter, (dlist_head *) &wakeup) > > { > > PGPROC *waiter = dlist_container(PGPROC, lwWaitLink, iter.cur); > > LOG_LWDEBUG("LWLockRelease", l, mode, "release waiter"); > > dlist_delete(&waiter->lwWaitLink); > > pg_write_barrier(); > > waiter->lwWaiting = false; > > PGSemaphoreUnlock(&waiter->sem); > > } > > .. > > } > > > > Why can't we decrement the nwaiters after waking up? I don't think > > there is any major problem even if callers do that themselves, but > > in some rare cases LWLockRelease() might spuriously assume that > > there are some waiters and tries to call LWLockWakeup(). Although > > this doesn't create any problem, keeping the value sane is good unless > > there is some problem in doing so. > > That won't work because then LWLockWakeup() wouldn't be called when > necessary - precisely because nwaiters is 0. Err, this is bogus. Memory fail. The reason I've done so is that it's otherwise much harder to debug issues where there are backend that have been woken up already, but haven't rerun yet. Without this there's simply no evidence of that state. I can't see this being relevant for performance, so I'd rather have it stay that way. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: