[cpp-threads] modes, interlude

[Boehm, Hans]

I agree that's an open issue.  I don't have a solution, but I'm also
not yet convinced there isn't one.

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 Doug Lea
> Sent: Monday, May 09, 2005 4:29 PM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] modes, interlude
> 
> 
> Boehm, Hans wrote:
> > Some higher level issues before we dive back into the details:
> > 
> > 1) I think the implicit assumption in this discussion has been that 
> > the simplest solution has been the one with the smallest number of 
> > primitives, where a primitive is a memory operation with an 
> ordering 
> > constraint.  I'd actually like to see us minimize the number of 
> > ordering constraints, but implement each ordering constraint with 
> > every memory operation for which it makes any sense at all. 
>  It seems 
> > to me that disallowing meaningful combinations actually adds 
> > complexity.  (I think the discussion sort of moved there 
> anyway, but I 
> > wanted to make it
> > explicit.)
> > 
> 
> The main issue here is:
> 
> Programs using raw (or weirdly moded) loads and stores of 
> atomics would have races, and hence undefined semantics if we 
> treated those the same way as ordinary variables. So we can't 
> treat them as races in that sense.
> 
> But if we define their semantics, why don't we do so for
> all programs, even those with races in ordinary variables?!
> 
> I gave a shot to only supporting a few modes for atomics that
> I thought we wouldn't have much trouble spec'ing out.
> But didn't see a good way to do it.
> 
> Do you see a way out of this?
> 
> -Doug
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk