Re: [boost] Threads Review

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 08:30:39

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.

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, 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.

let's-leave-that-to-mr-boehm-ly y'rs,

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html