[cpp-threads]atomic operations package

[Boehm, Hans]

Doesn't msync::ddhlb just turn into acquire, and msync::ssb into
release?  Thus I think the only issue here is a possible
performance loss.

There are issues here where I think we still have choices that should
be discussed:

1) You make the ordering constraint a run-time parameter, and I make
it a member template parameter.  My guess is that you almost never want
it
to be a runtime parameter.  My approach guarantees that it never
accidentally turns into one.  (With sufficient inlining and
constant propagation you should get the same code in both cases,
I would think.  With a stupid compiler, the templates probably win.)

However, in the absence of some practical experimentation,
I'm never quite sure that such things won't get in
the way of overload resolution or the like.  There may be reasons
my approach won't quite fly.  Or someone may have good argument
that it needs to be a run-time parameter.  (You can still
make it one with the obvious wrapper containing a switch
statement.)

2) I'm still not sure whether there is a reason to introduce
ordering constraints that are limited to loads or stores, as opposed
to acquire and release which apply to both.  If we can get away
without it, that would simplify matters.  And I think that if we don't
make implicit assumptions about data dependencies enforcing ordering
then limiting ordering to just loads or stores is probably often a bug.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Alexander Terekhov
> Sent: Monday, August 22, 2005 11:03 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads]atomic operations package
> 
> 
> On 8/22/05, Hans Boehm <Hans.Boehm at hp.com> wrote:
> [...]
> > > 
> http://blogs.sun.com/roller/page/pgdh?entry=caring_for_the_environme
> > > nt_making
> > >
> > I don't understand the problem here.  The code there 
> contains another 
> > instance of broken double-checked locking.  The only use of 
> a memory 
> > barrier I see could easily be translated to our current proposal.
> 
> I don't think so. Intentional leaking (together with real GC or 
> hazards) aside for a moment, Phil Harman is driving at atomic<>ized 
> Andrei's WRRMMap, I think.
> 
> http://groups.google.com/group/comp.std.c++/msg/3d48651534c866f8
> 
> How would you translate it to the current proposal?
> 
> regards,
> alexander.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk