From: Darryl Green (green_at_[hidden])
Date: 2001-08-07 03:41:29
> From: Beman Dawes
> I have an app where the main thread opens an ifstream
> automatic (stack)
> object. There's a static storage mutex protecting it. A
> pointer to the
> ifstream object gets passed to worker threads. The worker
> threads read
> input records to be processed from the stream.
> That's totally commonplace code. It has to be conforming;
> C++ doesn't
> have a notion of pointer to automatic being different from pointer to
> static or pointer to dynamic memory.
Well that answers John Max Skaller's original post:
> Question: does anyone share stack data between threads?
I do realise C++ will be perfectly happy for you to
do this. I don't really know the context of the original
discussion that lead to the question. I had assumed that
the issue was whether any guarantees could or needed to
be made about the consequences of doing this.
My pesimistic attitude has been to assume that any thread
may die unexpectedly (unexpectedly so far as other threads
are concerned) and that the consequences of this for any
thread sharing data located on the dead/dying threads
stack are too horrible to contemplate.
Obviously the "main thread" has special status in
most (all?) systems so that it is possible to get
away with this sort of thing for that one special
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk