[v3] api docs
Mon Dec 10 02:10:00 GMT 2007
On 10/12/2007, Benjamin Kosnik <email@example.com> wrote:
> 2) _GLIBCXX_ATOMIC_BUILTINS versus __default_lock_policy's
The latter exists specifically because the former is too broad and
doesn't guarantee that builtin CAS is available. IIRC configure
defines ATOMIC_BUILTINS if fetch-and-add is builtin, but fetch-and-add
is not a universal atomic primitive and can't be used to implement
arbitrary synchronisation operations, unlike CAS.
If configure checked for builtin CAS before defining ATOMIC_BUILTINS
it would mean builtin fetch-and-add and exchange-and-add would not be
used on some platforms where they are available.
I'm not sure what can be done other than asking the compiler folks to
pre-define macros like HAVE_SYNC_FETCH_AND_ADD to make the configure
test unnecessary, but I don't see any benefit to that.
The attached patch fixes some typos and markup.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8277 bytes
Desc: not available
More information about the Gcc-patches