Re: [boost] Re: Boost.Threads - name of the "thread" type

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-22 13:44:31

williamkempf_at_[hidden] wrote:

> Which is something that can be done when the C++ standards committee
> chooses to adopt a threads concept, and we do hope that the Boost
> effort is considered at that time.  However, the Boost effort can't
> address this, because we can't change the abstract machine (at least
> not easily or portably).  

        Of course. I think the boost effort is important,
because if it can be got to work on several architectures,
then the interface will demonstrate what actually
needs to be changed in the abstract machine in order that
the specifications are meaningful.

> That's why I've said that cancellation
> *may* be considered.  It is a feature that most people are going to
> want... and that despite the fact that historical evidence shows it
> to be dangerous even when it's a part of the language.  

        I'm not an expert, but a person who is has told me that
without cancellation, threads are useless except as toys.
His complaint was that Posix cancellation is incomplete,
and that the behaviour under C++ (wrt destructors, etc)
is unspecified. For sophsiticated system, you end up
being forced to fix a particular platform (in this case
a particular version of Solaris).

        Boost threads cannot solve this problem, as you say.
Neither can the committee, without something which purports
to being a reasonable threads library (in terms of both semantics
and portability).

        Since I think modern programming must include
a notion of multiprocessing, I can only commend the
effort to build a portable threads library -- even 
if the specifications are non-sense in terms of the
existing C/C++ abstract machine model.

> >       [Best not to start me off on a rant :-]
> 
> Hey, I dislike Java as much as the next guy, but Java has shown many
> of the dangers in a poor thread design that every language/library
> should pay attention to.  Cancellation is a big one.  I'm not sure
> that a safe form of cancellation can be done, despite how easy it is
> to add cancellation explicitly to thread routines.

        The current notion of threads is poor.
There are much better solutions. For example the behaviour
of the JoCaml system is backed by a mathematical calculus
(the join calculus). 

        For the moment though, we can only wrap the poorly
designed concepts and API's that are actually made available,
providing some extra safety where possible, but otherwise
leaving it up to the programmer.
 
> You're bringing up another issue here that's pertinent to only a
> portion of designs that need cancellation.  For realtime systems that
> need immediate cancellation (i.e. they can't wait until after a
> return from a blocking routine) a wrapper is going to be problematic
> and a library supplied cancellation mechanism is likely going to be a
> necessity.  However, experience shows this need to be in the
> minority, so weighing the pros and cons leaves me still wanting to
> ignore cancellation.

        That's fine by me. As I said above, the key thing
here is to get _something_ that supports a reasonable class
of threaded programs: not so much because the library would
be useful if ISO Standardised, but because the mere 
consideration of it will force the abstract machine to
be upgraded. At worst, such an upgrade will allow
non-standard, proprietary, solutions to be provided
with specifications that actually have a meaning.
That would be a major step forward.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net