Re: [v3] api docs

[Benjamin Kosnik <bkoz at redhat dot com>]

> > 2) _GLIBCXX_ATOMIC_BUILTINS versus __default_lock_policy's
> > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
> 
> 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.

Configure defines _GLIBCXX_ATOMIC_BUILTINS if __sync_fetch_and_add
exists.

There is no use of CAS (via __sync_bool_compare_and_swap or
__sync_val_compare_and_swap) or other atomic builtins in
libstdc++. 

The only place it appears to be used is __default_lock_policy. And
parallel mode. I'm working on 34106....

I'd like to see a coherent lock policy for the whole library integrated
into the ext/concurrency.h choices. It might mean that we need more
choices in _Lock_policy. It might mean that the configure tests for
_GLIBCXX_ATOMIC_BUILTINS gets adjusted.

Right now, _GLIBCXX_ATOMIC_BUILTINS can be defined, but
__default_lock_policy can be something else non-atomic. This seems
incorrect to me.

> 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 quite sure I follow.

> The attached patch fixes some typos and markup.

Thanks. Please put these in immediately.

I was looking for a good firefox extension
for doing W3C validation of local files, so I could see status on my
local edits pre-checkin, but didn't have much luck. (And then I
switched to konq so I could print 2-up anyway...) 

I need to look at Doug's reply to documentation technology and start in
on this stuff before I continue with much more documentation hacking.

-benjamin