[cpp-threads]atomic operations package

[Alexander Terekhov]

On 8/15/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> It seems to me that we will have to make some serious compromises here.
> In some cases, we will not be able to generate the fastest
> possible code for every algorithm without resorting to assembly
> code.

Folks won't grok it. Here's yet another illustration:

http://blogs.sun.com/roller/page/pgdh?entry=caring_for_the_environment_making

[...]

> I haven't thought about ordering constraints on reference counting
> in a while.  I think the constraints we need to enforce are:
> 
> 1) Updates to a specific reference count within a thread become visible
> in order.  I'd be inclined to say that this should be a property
> of even unordered atomic writes.
> 
> 2) Field accesses need to be visible before the corresponding reference
> count decrement.
> 
> 3) The final reference count decrement needs to be visible before
> the memory is deallocated and reused in a different thread.  I would
> expect the memory allocator to handle that as part of it's shared
> state update, e.g. with a release-store to a shared free list.
> 
> I think (2) can be handled with a release constraint on the decrement,
> which also handles (1), if necessary.  This seems slightly suboptimal
> on some architectures, but not horrible.  Am I missing something?

http://gcc.gnu.org/ml/libstdc++/2005-04/msg00075.html
http://gcc.gnu.org/ml/libstdc++/2005-04/msg00102.html

regards,
alexander.