[cpp-threads] memory model

[Boehm, Hans]

I think there are two uses of volatile here that bother me, in
that they look legitimate to me, and we would slow them down:

1) The setjmp/longjmp use.  I suspect that's relatively rare, but
it is explicitly sanctioned.  In my warped experience, that one's
funny because it tends to impose requirements that are
orthogonal to all other uses of volatile.  In particular, it tends
to force a completely unshared, address-not-taken local variable out
of a register, which I think is otherwise not what you want.

2) The mmap use.  This is unusual, in that the external agent modifying
the location is the thread itself, and hence it's synchronous.
(Getting this to work correctly with a virtually indexed cache
seems tricky in any case.  But AFAICT kernels seem to go through
the trouble.  Google mmap "virtually indexed cache".)

I'm not convinced by the signal handler or thread example, since
I think we can come up with "conforming" DSM implementations on
which those break.  And I don't think "volatile" is currently guaranteed
to be async-signal-safe anyway.

I'd be fine with the extra qualifier.  (Is this becoming our
canonical solution for all problems?)  But I would still like to
pin down what the qualified and unqualified versions of volatile
mean.

I don't think we can say "volatile" means "no compiler reordering".
That doesn't make sense to the user, and I doubt it's expressible
in standardese.  And compilers already disagree as to
how much reordering is allowed w.r.t. ordinary memory references,
and whether memory barriers are implied.  (Gcc disagrees with
itself across platforms, and in my opinion, isn't internally
consistent on Itanium, the one platform where I've tried to look
at this.)  Up until now, this could be dodged to some extent by
saying the standard didn't address concurrency issues.  We're
losing that excuse.

I think I hear roughly

volatile = safe for "unexpected" but synchronous modification from same
thread.

mutable volatile = safe for asynchronous modification.

That would force uses from asynchronous signal handlers to use
"mutable volatile"?  Is "volatile" good enough if (assuming pthreads,
where that's possible) we force the handler to run in the same thread?

Is "mutable" a C keyword these days?  If not, that would be an
unpleasant
divergence.  I'd suggest "__thread volatile", but I think that already
has different semantics.

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: Friday, April 29, 2005 5:22 AM
> To: Jason Merrill
> Cc: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] memory model
> 
> 
> On 4/29/05, Jason Merrill <jason at redhat.com> wrote:
> [...]
> >  http://gcc.gnu.org/ml/gcc/2005-04/threads.html#00724
> 
> http://gcc.gnu.org/ml/gcc/2005-04/msg01313.html
> 
> regards,
> alexander.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk