Latches with weak memory ordering (Re: max_wal_senders must die)
От | Heikki Linnakangas |
---|---|
Тема | Latches with weak memory ordering (Re: max_wal_senders must die) |
Дата | |
Msg-id | 4CE0DDFC.7090801@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: max_wal_senders must die (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Latches with weak memory ordering (Re: max_wal_senders
must die)
|
Список | pgsql-hackers |
On 14.11.2010 22:55, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes: >> On 13.11.2010 17:07, Tom Lane wrote: >>> Robert Haas<robertmhaas@gmail.com> writes: >>>> Come to think of it, I'm not really sure I understand what protects >>>> SetLatch() against memory ordering hazards. Is that actually safe? >>> >>> Hmm ... that's a good question. It certainly *looks* like it could >>> malfunction on machines with weak memory ordering. > >> Can you elaborate? > > Weak memory ordering means that stores into shared memory initiated by > one processor are not guaranteed to be observed to occur in the same > sequence by another processor. This implies first that the latch code > could malfunction all by itself, if two processes manipulate a latch at > about the same time, and second (probably much less likely) that there > could be a malfunction involving a process that's waited on a latch not > seeing the shared-memory status updates that another process did "before" > setting the latch. > > This is not at all hypothetical --- my first attempt at rewriting the > sinval signaling code, a couple years back, failed on PPC machines in > the buildfarm because of exactly this type of issue. Hmm, SetLatch only sets one flag, so I don't see how it could malfunction all by itself. And I would've thought that declaring the Latch variable "volatile" prevents rearrangements. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: