Date: 2001-06-22 14:04:20
--- In boost_at_y..., John Max Skaller <skaller_at_o...> wrote:
> williamkempf_at_h... wrote:
> > That's why I've said that cancellation
> > *may* be considered. It is a feature that most people are going
> > want... and that despite the fact that historical evidence shows
> > 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).
Other experts tell you that traditional threading systems are useless
except as toys. However, these "toys" are the building blocks of
other sytems. Cancellation, on the other hand, is only a concept
required by a select few real time applications. Most MT
applications can be (and often are) coded with either no
cancellation, or with application specific cancellation mechanisms
using condition variables or other synchronization concepts.
> 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.
What we have so far is hardly "non-sense" in terms of the existing
C/C++ abstract machine model, even if we are extending it to include
the concept of a thread of execution.
> > > [Best not to start me off on a rant :-]
> > Hey, I dislike Java as much as the next guy, but Java has shown
> > 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
> > 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).
CSP calculus is the latest in state of the art threading concepts.
However, CSP systems are usually built using the lower level
primitives, and it is a goal of Boost.Threads to include these higher
level concepts at some point. I feel compelled to point out that CSP
systems don't support cancellation, however, which makes your
expert's assertion questionable.
> 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.
We can do much more than this, and it is the ultimate goal. However,
you have to build the wheels before you can build the formula one
racer. In this case, there's a very large set of existing practice
using the lower level primitives that illustrate their usefullness
even if the higher level concepts are "safer".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk