RE: [boost] Re: boost.threads

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-07 09:52:01

At 04:41 AM 8/7/2001, Darryl Green wrote:

 >I have had a look at the definitions section of the
 >Boost.Threads docs and in particular the following row
 >of the table of sequence points at which the value of
 >an object as if accessed by thread A at the indicated
 >sequence point will be determinate and the same if
 >accessed at or after the indicated thread B sequence
 >point:
 >
 >A: The last sequence point before thread termination.
 >
 >B: The sequence point after a call to a library function
 >which joins the terminated thread.
 >
 >This implies strongly that the system must preserve the
 >terminated thread's stack until the terminated
 >thread is joined (which could obviously be at any time
 >until the whole process is terminated).
 >Surely this is not intended?

There are two issues; the lifetime of objects and the visibility of object 
values.

The lifetime of a function's automatic (stack) storage even in a 
multi-threaded program is determined by the normal rules of C++.  Thus as 
always it is undefined behavior to reference an object of automatic storage 
after the function has returned.

What the table (which is based on page 89 of Butenhof's "Programming with 
POSIX Threads") is talking about is "Memory visibility between 
threads".  In other words, the requirements that must be met before a 
thread can dereference memory and obtain a value that is the same as the 
value previously written to that same memory by another thread.

Naively, someone might think that as long as the write occurred at least 
one clock tick before the read, the read would get the correct value.  In 
reality, multiple processors, caches, and other hardware issues lead to 
much more complicated rules.  Thus the table.

I've changed the section title to "Memory visibility between threads" to 
try to make that clearer.

--Beman