Re: better atomics - v0.5
От | Andres Freund |
---|---|
Тема | Re: better atomics - v0.5 |
Дата | |
Msg-id | 20140626112148.GC1926@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: better atomics - v0.5 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: better atomics - v0.5
|
Список | pgsql-hackers |
On 2014-06-25 20:22:31 -0400, Robert Haas wrote: > On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: > > I think having a separate file for each architecture is nice. I totally > > agree that they don't belong in src/include/storage, though. s_lock.h has > > always been misplaced there, but we've let it be for historical reasons, but > > now that we're adding a dozen new files, it's time to move them out. > > I find the current organization pretty confusing, but maybe that could > be solved by better documentation of what's supposed to go in each > architecture or compiler-dependent file. The idea is that first a architecture specific file (atomics-arch-*.h) is included. That file can provide a (partial) implementation for the specific architecture. Or it can do pretty much nothing. After that a compiler specific file is included (atomics-generic-*.h). If atomics aren't yet implemented that can provide an intrinsics based implementation if the compiler version has support for it. At the very least a compiler barrier should be provided. After that the spinlock based fallback implementation (atomics-fallback.h) provides atomics and barriers if not yet available. By here we're sure that nothing else will provide them. Then we can provide operations (atomics-generic.h) that build ontop of the provided functions. E.g. implement _sub, _and et al. I'll include some more of that explanation in the header. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: