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