Re: better atomics - v0.6
От | andres@anarazel.de (Andres Freund) |
---|---|
Тема | Re: better atomics - v0.6 |
Дата | |
Msg-id | 20140924165756.GS2521@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: better atomics - v0.6 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: better atomics - v0.6
|
Список | pgsql-hackers |
On 2014-09-24 12:44:09 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-09-24 18:55:51 +0300, Heikki Linnakangas wrote: > >> There doesn't seem to be any hardware implementations of that in the patch. > >> Is there any architecture that has an instruction or compiler intrinsic for > >> that? > > > You can implement it rather efficiently on ll/sc architectures. But I > > don't really think it matters. I prefer add_until (I've seen it named > > saturated add before as well) to live in the atomics code, rather than > > reimplement it in atomics employing code. I guess you see that > > differently? > > I think the question is more like "what in the world happened to confining > ourselves to a small set of atomics". I fail to see why the existance of a wrapper around compare-exchange (which is one of the primitives we'd agreed upon) runs counter to the agreement that we'll only rely on a limited number of atomics on the hardware level? > I doubt either that this exists > natively anywhere, or ethat it's so useful that we should expect platforms > to have efficient implementations. It's useful for my work to get rid of most LockBufHdr() calls (to manipulate usagecount locklessly). That's why I added it. We can delay it till that patch is ready, but I don't really see the benefit. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: