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
> 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
> 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 Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk