Date: 2001-06-28 13:33:24
Author: williamkempf (williamkempf_at_[hidden]) at unix,mime
Date: 27/06/01 17:23
> My concerns are:
>1) Will other operations that can be performed on threads create a
>very real need for a self() method?
I strongly suspect so. Any thread of execution that wishes to adjust
its own priority would need self.
>2) Should there be a join_all(). I'm becoming convinced there
>shouldn't be for various reasons, but with this design in particular
>the semantics will become difficult to detail. The join_all() method
>was first suggested by Jeremy Siek and it certainly makes some things
>simpler to deal with given some other designs, but since we can't
>know which threads are running at the point of call it's a dangerous
>call to make any way.
I think there should be a join_all, but only in the context of
thread groups. A join_all without thread groups would be very
dangerous in the presence of third party libraries that may not need
to document their thrad policies where it is implementation detail.
>3) Should there be comparison operators? With out copy semantics
>you'd always be comparing to yourself, so I'd guess not.
Not sure. I need to think about this some more.
>4) Will the usage of this design make users opt for the native C
>APIs instead of the Boost.Threads library. Even if the design is
>superior (I won't claim it is, though that was the goal of everyone
>here) if no one will use it then the design is a failure.
Probably. Particularly those that that use C++ as a better C and
those that believe ( mostly incorrectly ) that they can't afford to
pay for the overhead.
The approach I would prefer is a two layered approach as proposed by
Beman. This is also the approach used be Doug Schmidt in the ACE
threads library ( http://www.cs.wustl.edu/~schmidt )
ACE has a low level wrapper thread class with all the methods
static. It is basically a wrapper based on pthreads but is os and
thread platform indepentant. I.e. it runs on pthreads, Solaris LWP,
Win32 threads, VxWorks threads, & pSoS threads.
It then defines a number of higher level abstractions based on this
The low level wrapper gives people confidence that if they can't do
something in the higher level abstraction they can always drop down
to the lower.
>5) Are the join(), detach() and destructor semantics
>understandable and usable? For example, what happens if you call a
>method on a thread object that's been detached? I would expect an
>error. If that's the case should join() detach the thread, or
>simply wait for the thread to finish, being a noop if the thread is
>already finished? Should the destructor detach() the thread or
>join() it? 6) Should sleep() and yeild() be stand alone methods,
>and why? We'll need good rationale statements for this which ever
>route we go. The rationale for making them static methods is to
>give them access to thread internals, but both current target
>implementations do not have this need, and it's possible
>(probable?) that no implementation will need this.
I think join should wait and be a noop if the thread has ended. This
is needed for parallel computation or 'divide & conquor' algorithims
such as calculating a fibonacci number using multiple thread. The
parent thread kicks of a number of threads to do this and waits for
I originally thought the destructor should detach as this seemed
most logical. However, it is, I believe, dangerous and a potential
resource leak especially if the main thread exits.
I don't think that we should use stand alone methods in a namespace
for yield ( ) and sleep ( ) unless there is a compelling technical
reason. This follows the principle of least supprise. I think that
most programmers would expect to find these as static methods on the
class, whether they were experienced with threads or not.
Standalone methods have in the past, typically been created only
where necessary such as where they have to be associative.
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk