Re: Atomics hardware support table & supported architectures
От | Andres Freund |
---|---|
Тема | Re: Atomics hardware support table & supported architectures |
Дата | |
Msg-id | 20140623163817.GW16260@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Atomics hardware support table & supported architectures (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2014-06-23 09:28:19 -0700, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund <andres@2ndquadrant.com> wrote: > >> Since fetch-and-add is trivially implemented using CAS, there's not much > >> need to distinguish between CAS and CAS + fetch_and_add. From my POV the > >> restriction to just CAS/fetch_and_add isn't actually buying much. Pretty > >> much all platforms but older gcc ones have atomic intrinsics since > >> forever. Once you've dug up the documentation for one operation not > >> adding two more or so doesn't save much. > > > Again, the concern that was expressed at the developer's meeting was > > that the performance characteristics of the CAS loop might be > > significantly different from a native atomic op as to cause us > > heartburn. I think that's a valid concern... but if everything in > > common use has both CAS and fetch-and-add, then I think there's > > probably no issue here. > > What I want to know is whether we are going to agree that the set of > atomics is going to be CAS plus fetch_and_add plus *nothing else*. It's going to be TAS, CAS, fetch_and_add, right? Since TAS is the only thing supported on some platforms? The only op I'm currently wondering about adding is a atomic exchange, without compare to that set. All platforms that support CAS also have a non-comparing version of it. Right now the patch also uses __sync_fetch_and_sub() in the generic gcc implementation instead of doing the negation itself, but that's easily "fixable". > Andres seems to envision that those will be a minimal set and then > we'll freely use any other atomic op that seems handy as long as we can > provide a fallback implementation of it. Well, I *do* also want pg_atomic_fetch_and/or_u32() - but I'm totally fine with those two only being implemented with CAS. On all platforms. Otherwise the next scalability patch I'm going to submit will just have to open code a CAS loop for it which doesn't seem to help. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: