|
Boost : |
From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-07 16:09:10
Darryl Green wrote:
> Well that answers John Max Skaller's original post:
> > Question: does anyone share stack data between threads?
It does, however:
> I do realise C++ will be perfectly happy for you to
> do this.
no: it will be happy if an only if the abstract
machine is extended to support interthread sharing
of stack data. At present, C++ is very unhappy
immediately you create a thread: all bets are off.
> I don't really know the context of the original
> discussion that lead to the question.
I believe I misread one of Bemans statements
in his proposed threading model document, to say that
stack data could NOT be shared between threads.
> I had assumed that
> the issue was whether any guarantees could or needed to
> be made about the consequences of doing this.
That's a different (kind of) issue, the kind
Bill is trying to deal with by providing a library
that at least _helps_ do thread safe programming
a bit more easily (meaning both safely and portably).
Generally, the abstract machine is just there
so you can say things .. not to provide any safety.
Occasionally, it can be characterized in such a way that
some optimisations are possible.
For example: suppose to create an object
T const *p= new (T const)(x,y)
and then write:
*const_cast<T*>(p) = T()
Is that legal? If T has a nontrivial constructor, then T
must be created in writable RAM, or the constructor cannot
set the members. but is the implementation permitted to
hardware write protect the memory AFTER the constructor
has run .. which would cause the assignment above
to fault? Is that a valid implementation of C++?
What if you exploit the well know 'this' loophole?
['this' in a constructor is always non-const, so you can
save it and use it to write to the object without a const cast,
but this only works for class types, which needed to be constructed
in RAM .. in the first place .. if it is legal, then write protection
of such 'const' objects is NOT permitted, and in fact they're
not 'const']
-- John (Max) Skaller, mailto:skaller_at_[hidden] 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 New generation programming language Felix http://felix.sourceforge.net Literate Programming tool Interscript http://Interscript.sourceforge.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk