Re: [boost] Re: Boost.Threads - thread_desc concept

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-29 21:53:55

Bill Klein wrote:
> 
> Greg Colvin wrote:
> > What happens if proc throws?
> 
> John Max Skaller wrote:
> > This is a core language matter.
> > Probably, terminate() is called. This is not an issue for this
> > library at this time.
> 
> Why do you say that? It's not a core language matter because the
> language doesn't yet talk about threads... That's the whole reason
> boost is creating the library! 

        I agree: sorry for being unclear.

> So pretend boost is actually making
> the std thread library and make a decision that way. It can easily
> be implemented to do something predictable (even if only terminate())
> so why not?

        What I should have said was:
it isn't _necessarily_ a library issue.

        In order to support threads at all, the abstract machine
must be updated. In that case, a core language issue
arises: what happens if an exception is thrown in
a thread, and there is no handler on the thread's stack?

        This question should be addressed.
It doesn't have anything to do with whether there is
a library for threads, at least, it doesn't
_necessarily_ have anything to do with it.
It could apply to raw Posix threads, launched
from C API calls.

        It is possible the committee says
"the result is unspecified". (or whatever) But i hope a better
_core language_ resolution is possible, because a lot
of programs out there use threads already.

        Nevertheless, if the result is unspecified (or whatever)
it is still possible, as you say, to encapsulate
a library in such a way that the issue doesn't arise
(for example wrapping the thread func in a catch all
exception handler) -- provided the user uses the
library (and uses it correctly, whatever that might mean).

        Obviously, it makes sense to do this
for the boost thread library at present,
since there isn't any core language resolution.
However, if a resolution comes, after the abstract machine
is upgraded, then the code can be removed from the library,
for conforming implementations of course,
since the core language will be required to implement the
trap anyhow.

        I recommend 'terminate()', because that is what I
believe the committee will decide on, and because it
is 'safe'. If the user wants anything else, they should
provide their own EH in the thread-func. An alternative
is to do nothing: delegate the decision to the core
working group.

        There are other issues. The most important one is:
WHEN can a thread rely on shared data?

        At present, the results of computations do not
have to be stored in memory until a sequence point.
This means accesses to the memory via an alias 
are indeterminate (or worse) until after a sequence point.

        For threads, there is a corresponding problem.
When is data written by one thread accessible to another?
One generic answer is 'after any synchronisation point'.
Which leaves the problem of defining synchronisation points.
The only obvious one is 'thread death'.
Another sensible candidate is 'yield()', and others include
'all blocking calls'. This is where a processor must
flush its cache to memory (if there are multiple CPUs).
Another solution is a specific 'flush_cache()' call.
Another is 'for volatile storage, after every sequence
point that storage is accessible'

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