Re: Shared locking in slru.c

Поиск
Список
Период
Сортировка
От Kenneth Marshall
Тема Re: Shared locking in slru.c
Дата
Msg-id 20051130210634.GA27311@it.is.rice.edu
обсуждение исходный текст
Ответ на Shared locking in slru.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Nov 30, 2005 at 03:23:55PM -0500, Tom Lane wrote:
> Kenneth Marshall <ktm@is.rice.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Dave Page"
Дата:
Сообщение: Re: [pgsql-www] Upcoming PG re-releases
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: [ADMIN] ERROR: could not read block