On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> Jason Merrill wrote:
>> 7 Accessing an object designated by a volatile lvalue (_basic.lval_),
>> modifying an object, calling a library I/O function, or calling a
>> function that does any of those operations are all side effects, which
>> are changes in the state of the execution environment. Evaluation of
>> an expression might produce side effects. At certain specified points
>> in the execution sequence called sequence points, all side effects of
>> previous evaluations shall be complete and no side effects of
>> subsequent evaluations shall have taken place.7)
>> My reading of this is that currently, a volatile read or write should act
>> as a barrier to other writes ("modifying an object"), because generally
>> there will be a sequence point between those writes and the volatile
>> access.
>
> Could you clarify whether 'other writes' means 'other _volatile_ writes',
> or '_any_ other writes'? Since non-volatile writes are not visible
> outside of the abstract machine, how can they be ordered wrt volatiles?
Any others. I was basing that on the requirement that the side-effects of
those writes are required to be complete, though I suppose you could argue
that they aren't required to be visible outside the current thread.
> It seems to me that threads require barriers _within_ the abstract machine,
> and currently there is no mechanism to specify just that. Volatile is all
> we have, and AFAICT those are only ordered WRT other volatile accesses
> separated by a sequence point.
>
> It appears to me that the proposal is providing more restrictions
> on volatile and other accesses, not fewer -- and cursorily that seems
> sane.
Yep.
Jason
