Re: Latches with weak memory ordering (Re: max_wal_senders must die)
От | Andres Freund |
---|---|
Тема | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |
Дата | |
Msg-id | 201011191731.42929.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: Latches with weak memory ordering (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)
Re: Latches with weak memory ordering (Re: max_wal_senders must die) |
Список | pgsql-hackers |
On Friday 19 November 2010 17:25:57 Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Locked statments like 'lock xaddl;' guarantee that the specific operands > > (or their cachelines) are visible on all processors and are done > > atomically - but its not influencing the whole cache like mfence would. > Where is this "locking the whole cache" meme coming from? What we're > looking for has nothing to do with locking anything. It's primarily > a directive to the processor to flush any dirty cache lines out to > main memory. It's not going to block any other processors. I was never talking about 'locking the whole cache' - I was talking about flushing/fencing it like a "global" read/write barrier would. And "lock xchgb/xaddl" does not imply anything for other cachelines but its own. I only used 'locked' in the context of 'lock xaddl'. Am I misunderstanding you? Andres
В списке pgsql-hackers по дате отправления: