From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2002-10-17 09:48:10
David Abrahams writes:
> Anthony Williams <anthony.williamsNOSPAM_at_[hidden]> writes:
>
> > David Abrahams writes:
> > > <anthony.williamsNOSPAM_at_[hidden]> writes:
> > >
> > > > David Abrahams writes:
> > > > > I suggest the following simple rewrite:
> > > > >
> > > > > "An object [1.8, 1.9] is accessible from multiple threads
> > > > >if it is of static storage duration (static, extern) [3.7.1],
> > > > >or if a pointer or reference to it is accessible from multiple
> > > > >threads."
> > > > >
> > > > > End of story.
> > > >
> > > > Except that it isn't --- the pointers and references need not
> > > > themselves be accessible from multiple threads for the pointed- or
> > > > referred-to object to be accessible from mutlple threads, if the
> > > > pointers or references are _copies_ of values accessible from
> > > > multiple threads.
> > >
> > > Fair enough. Yep, this wording is hard to get right. Got a suggestion?
> >
> > Actually, I'm inclined to think that your wording is right after
> > all. To get a pointer or reference which is not itself accessible
> > from multiple threads, but points/refers to an object that is, you
> > have to copy/take the address of/dereference another pointer or
> > reference which _is_ accessible from multiple threads.
>
> Yes, but that pointer-to-pointer may go out of scope, leaving the data
> still accessible through copies of the same pointer.
....a pointer or reference is _or has been_ accessible from multiple threads.
> In any case, I'm inclined to step back and see if there's a better way
> to accomplish what's being described in this part of the
> documentation. I don't think accessibility is actually important to
> what's being said, if you read carefully. My sense is that we want to
> say something like:
>
> If a thread reads or writes the value of an object while another
> thread is writing the value of that object,
or after such a write, without an appropriate intervening synchronization
primitive,
> the behavior of the
> program is undefined.
>
> And then we should go on to describe the temporal effects of the
> synchronization primitives. In other words, something like:
>
> Given a mutex M that is locked by some thread B, the sequence point
> after the library call in thread A which locks M follows the
> sequence point at the library call in thread B which unlocks mutex
> M.
>
> etc...
>
> I think from this you can get everything you need to know about the
> usability of shared data, without ever having to touch the sticky
> issue of accessibility.
You're probably right that this is a better way of describing it.
Anthony
-- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response.