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 201011191550.06550.andres@anarazel.de
обсуждение исходный текст
Ответ на Re: Latches with weak memory ordering (Re: max_wal_senders must die)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Friday 19 November 2010 15:14:58 Robert Haas wrote:
> On Thu, Nov 18, 2010 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> I'm all in favor of having some memory ordering primitives so that we
> >> can try to implement better algorithms, but if we use it here it
> >> amounts to a fairly significant escalation in the minimum requirements
> >> to compile PG (which is bad) rather than just a performance
> >> optimization (which is good).
> > 
> > I don't believe there would be any escalation in compilation
> > requirements: we already have the ability to invoke stronger primitives
> > than these.  What is needed is research to find out what the primitives
> > are called, on platforms where we aren't relying on direct asm access.
> 
> I don't believe that's correct, although it's possible that I may be
> missing something.  On any platform where we have TAS(), that should
> be sufficient to set the flag, but how will we read the flag?  A
> simple fetch isn't guaranteed to be sufficient; for some
> architectures, you might need to insert a read fence, and I don't
> think we have anything like that defined right now. 
A TAS is both a read and write fence. After that you don't *need* to fetch it.
And even if it were only a write fence on some platforms  - if we consistently 
issue write fences at the relevant places that ought to be enough.

Andres


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: 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)