|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-12 10:35:52
From: "Dale Peakall" <dale.peakall_at_[hidden]>
> On Monday 12 August 2002 3:39 pm, you wrote:
> > From: "William Kempf" <williamkempf_at_[hidden]>
> >
> > > This would, indeed, be a useful higher level construct. I'd point out
> > > that creating a thread on demand here would likely be a poor choice.
> >
> > A good implementation can transparently use a thread pool to provide
> > "instant" thread creation, _if_ creating a thread is a common
performance
> > bottleneck based on users' reports.
>
> Come on, it's going to entirely depend on an individual application as to
> whether a thread-pool is appropriate.
Perhaps we are using different definitions of "thread pool" and this is most
likely my fault. Let me rephrase.
An implementation can meet the specification as far as logical threads are
concerned but, behind the scenes, not terminate physical threads immediately
when logical threads terminate, in order to reuse them on the next logical
thread creation.
> I do not believe that a *good implementation* should ever do this. MT
> programs are fidly little beasts and trying to do things like this
> transparently in the library is just inviting disaster. The program
writer
> needs to know what threads exist in the system and what they're doing so
they
> can ensure that the interactions provide the intended behaviour, do not
> dead-lock, live-lock etc.
The program writer needs to know what logical threads exist, because this is
what is specified.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk