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 201011192003.27712.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)  (Andres Freund <andres@anarazel.de>)
Re: Latches with weak memory ordering (Re: max_wal_senders must die)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Friday 19 November 2010 18:46:00 Tom Lane wrote:
> I wrote:
> > Markus Wanner <markus@bluegap.ch> writes:
> >> Well, that certainly doesn't apply to full fences, that are not specific
> >> to a particular piece of memory. I'm thinking of 'mfence' on x86_64 or
> >> 'mf' on ia64.
> >
> > Hm, what do those do exactly?
>
> I poked around in the Intel manuals a bit.  They do have mfence (also
> lfence and sfence) but so far as I can tell, those are only used to
> manage loads and stores that are issued by special instructions that
> explicitly mark the operation as weakly ordered.  So the reason we're
> not seeing bugs is presumably that C compilers don't generate such
> instructions.
Well. Some memcpy() implementations use string (or SIMD) operations which are
weakly ordered though.

> Also, Intel architectures do guarantee cache consistency
> across multiple processors (and it costs them a lot...)
Only if you are talking about the *same* locations though. See example 8.2.3.4

Combined with:
"
For the Intel486 and Pentium processors, the LOCK# signal is always asserted
on the bus during a LOCK operation, even if the area of memory being locked is
cached in the processor.  For the P6 and more recent processor families, if
the area of memory being locked during a LOCK operation is cached in the
processor that is performing the LOCK operation as write-back memory and is
completely contained in a cache line, the processor may not assert the LOCK#
signal on the bus. Instead, it will modify the memory location internally and
allow it’s cache coherency mechanism to ensure that the operation is carried
out atomically. This operation is called “cache locking.” The cache coherency
mechanism automatically prevents two or more processors that have cached the
same area of memory from simultaneously modifying data in that area.
"

Which means something like (in intel's terminology) can happen:

initially x = 0

P1: mov [_X], 1
P1: lock xchg Y, 1

P2. lock xchg [_Z], 1
P2: mov r1, [_X]

A valid result is that r1 on P2 is 0.

I think that is not biting pg because it always uses the same spinlocks at the
reading and writing side - but I am not that sure about that.

Andres


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Latches with weak memory ordering (Re: max_wal_senders must die)
Следующее
От: David Fetter
Дата:
Сообщение: Re: UNNEST ... WITH ORDINALITY (AND POSSIBLY OTHER STUFF)