Re: [boost] Threads Review

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.