From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | lwlocks and starvation |
Date: | 2004-11-24 08:23:31 |
Message-ID: | 1101284611.12045.49.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
LWLockRelease() currently does something like (simplifying a lot):
acquire lwlock spinlock
decrement lock count
if lock is free
if first waiter in queue is waiting for exclusive lock,
awaken him; else, walk through the queue and awaken
all the shared waiters until we reach an exclusive waiter
end if
release lwlock spinlock
This has the nice property that locks are granted in FIFO order. Is it
essential that we maintain that property? If not, we could instead walk
through the wait queue and awaken *all* the shared waiters, and get a
small improvement in throughput.
I can see that this might starve exclusive waiters; however, we allow
the following:
Proc A => LWLockAcquire(lock, LW_SHARED); -- succeeds
Proc B => LWLockAcquire(lock, LW_EXCLUSIVE); -- blocks
Proc C => LWLockAcquire(lock, LW_SHARED); -- succeeds
i.e. we don't *really* follow strict FIFO order anyway.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-11-24 08:26:41 | Re: Bitmap index |
Previous Message | Arnold.Zhu | 2004-11-24 07:20:30 | Re: How to make @id or $id as parameter name in plpgsql, is it available? |