On 02/12/2014 06:10 PM, Ants Aasma wrote:
On Wed, Feb 12, 2014 at 4:04 PM, knizhnik <knizh...@garret.ru> wrote:
Even if reordering was not done by compiler, it still can happen while
execution.
There is no warranty that two subsequent assignments will be observed by all
CPU cores in the same order.
The x86 memory model (total store order) provides that guarantee in
this specific case.
Regards,
Ants Aasma
Sorry, I thought that we are talking about general case, not just x86
architecture.
May be I do not understand something in LWlock code, but it seems to me that
assigning NULL to proc->lwWaitLink is not needed at all:
while (head != NULL)
{
LOG_LWDEBUG("LWLockRelease", lockid, "release waiter");
proc = head;
head = proc->lwWaitLink;
>>> proc->lwWaitLink = NULL;
proc->lwWaiting = false;
PGSemaphoreUnlock(&proc->sem);
}
This part of L1 list is not traversed by any other processor. So nobody will
inspect this field. When awakened process needs to wait for another lock,
it will just assign NULL to this field itself:
proc->lwWaiting = 1;
proc->lwWaitMode = mode;
>>> proc->lwWaitLink = NULL;
if (lock->head == NULL)
lock->head = proc;
else
lock->tail->lwWaitLink = proc;
lock->tail = proc;
Without TSO (total store order), such assignment of lwWaitLink in LWLockRlease
outside critical section may just corrupt L1 list, in which awakened process is
already linked.
But I am not sure that elimination of this assignment will be enough to ensure
correctness of this code without TSO.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
