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 по дате отправления: