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

From: Iain.Hanson_at_[hidden]
Date: 2001-06-28 13:33:24

Author:  williamkempf (williamkempf_at_[hidden]) at unix,mime
Date:    27/06/01 17:23

[snip]

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

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 
the result.

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.

/ikh
     
     

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.