From: | Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kenneth Marshall <ktm(at)is(dot)rice(dot)edu>, pqsql-hackers(at)postgresql(dot)org |
Subject: | Re: Shared locking in slru.c |
Date: | 2005-11-30 21:06:34 |
Message-ID: | 20051130210634.GA27311@it.is.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 30, 2005 at 03:23:55PM -0500, Tom Lane wrote:
> Kenneth Marshall <ktm(at)is(dot)rice(dot)edu> writes:
> > ... In pseudo-code, the operations to
> > read the control information are:
>
> > WriteControl:
> > 1. Set latch.
> > 2. Update control information
> > 3. Increment latch version number.
> > 4. Unset latch.
>
> > ReadControl:
> > 1. Read latch version number.
> > 2. Read control information.
> > 3. Check latch. If locked go to step 1.
> > 4. Read latch version number. If the value is different from the
> > value read in step 1, go to step 1.
>
> Hm, I don't see how that's safe in the presence of concurrent would-be
> writers? (Or is that what you meant by "queuing up lock requests"?)
>
> regards, tom lane
The latch is definitely safe for readers and writers concurrently
accessing the information. It does not provide the ordered waiting
for a lock that the LWLock will. It is also so light-weight that
for the types of reads and updates to the shared areas that it may
outperform the existing LWLock even during contention.
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2005-11-30 21:09:16 | Re: [ADMIN] ERROR: could not read block |
Previous Message | Kenneth Marshall | 2005-11-30 20:18:40 | Re: Shared locking in slru.c |