Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit86b9424

Browse files
committed
Prevent potentially hazardous compiler/cpu reordering during lwlock release.
In LWLockRelease() (and in 9.4+ LWLockUpdateVar()) we release enqueuedwaiters using PGSemaphoreUnlock(). As there are other sources of suchunlocks backends only wake up if MyProc->lwWaiting is set to false;which is only done in the aforementioned functions.Before this commit there were dangers because the store to lwWaitLinkcould become visible before the store to lwWaitLink. This could bothhappen due to compiler reordering (on most compilers) and on someplatforms due to the CPU reordering stores.The possible consequence of this is that a backend stops waitingbefore lwWaitLink is set to NULL. If that backend then tries toacquire another lock and has to wait there the list could becomecorrupted once the lwWaitLink store is finally performed.Add a write memory barrier to prevent that issue.Unfortunately the barrier support has been only added in 9.2. Giventhat the issue has not knowingly been observed in praxis it seemssufficient to prohibit compiler reordering using volatile for 9.0 and9.1. Actual problems due to compiler reordering are more likelyanyway.Discussion: 20140210134625.GA15246@awork2.anarazel.de
1 parent789c5b0 commit86b9424

File tree

1 file changed

+15
-5
lines changed

1 file changed

+15
-5
lines changed

‎src/backend/storage/lmgr/lwlock.c

Lines changed: 15 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -647,12 +647,22 @@ LWLockRelease(LWLockId lockid)
647647
*/
648648
while (head!=NULL)
649649
{
650+
/*
651+
* Try to guarantee that lwWaiting being unset only becomes visible
652+
* once the unlink from the link has completed. Otherwise the target
653+
* backend could be woken up for other reason and enqueue for a new
654+
* lock - if that happens before the list unlink happens, the list
655+
* would end up being corrupted. In later releases we can rely on
656+
* barriers, but < 9.2 doesn't yet have them - so just use volatile.
657+
*/
658+
volatilePGPROC*p;
659+
650660
LOG_LWDEBUG("LWLockRelease",lockid,"release waiter");
651-
proc=head;
652-
head=proc->lwWaitLink;
653-
proc->lwWaitLink=NULL;
654-
proc->lwWaiting= false;
655-
PGSemaphoreUnlock(&proc->sem);
661+
p=head;
662+
head=p->lwWaitLink;
663+
p->lwWaitLink=NULL;
664+
p->lwWaiting= false;
665+
PGSemaphoreUnlock((PGSemaphore)&p->sem);
656666
}
657667

658668
/*

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp