Re: Threads: what I wrote...

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-09 09:16:40

--- In boost_at_[hidden], "Gernot Neppert" <gn_at_l...> wrote:
> --- In boost_at_[hidden], "William Kempf" <sirwillard_at_m...> wrote:
> > This is the "thin wrapper" that I dislike.  Now we must derive 
from 
> > thread (or in other implementation, derive from runnable or some 
> > other suitably named secondary class) in order to be an "active 
> > object" and the active object is the only form of thread routine 
> > available.  A thread creation routine that truly took C++ into 
> > consideration would allow you to create a thread from any 
function 
> or 
> > any member function or even from some arbitrary functor.  As the 
> > caller I should be able to supply what ever arguments I want to 
to 
> > the "routine" that runs in the thread.  The C callback approach 
> isn't 
> > really appropriate in C++.  Instead, think "slots for threads".
> > 
> 
> This has been discussed at length in comp.programming.threads, and 
> most of the people there agreed that just providing a thread base 
> class was not sufficient. Still, I do think that the proposed code 
> should be part of the solution, since it's a very versatile 
starting 
> point. Providing a base thread class or, even better, a pluggable 
> abstract "runnable" class gives you a lot of options: Deriving 
> template classes from "runnable" that accept function pointers or 
> function objects together with arbitrary data ist quite 
> straightforward. These classes, together with functions that create 
> them - something like "template<typename Func> runAsThread( 
Func )" -
> should of course be included in the library. 
> Plus, you still have that pure interface that you can impelement in 
> your own classes.

Personally, to me the thread class should not be used as a base 
class.  I see a very distinct seperation of a "thread" and the 
process that's run within the thread.  A runnable class is better, 
but I don't care for it either.  This imposes a class heirarchy 
decision on all code that will use threads from that point on.  Any 
time you can avoid a class heirarchy I think you've made the code 
more reusable and easier to deal with.  A "slot as thread proc" 
approach will allow complete flexibility in design, including any and 
all designs that you'd do with base thread or runnable classes.

> >>[mutex should not be copyable]
> > I'm not sure I agree here.  If the mutex isn't copyable this 
means 
> > that any class that contains a mutex (to handle internal 
> > synchronization) then the class is either not copyable or code 
must 
> > be supplied within every such class to deal with the issue.  
> 
> ...which is, IMHO, quite good. If you design a class that contains 
a 
> mutex member and the compiler-generated copy-ctor "copies" that 
> mutex, thus effectively creating shared access to a system 
resource, 
> your new class object becomes linked to another object, something 
> that you most probably didn't want! Wouldn't it be better to be 
> forced to manually encode the copy-ctor then, and probably default-
> initialize the mutex member?

Maybe.  I don't think it's cut and dried, and the decision will be 
based (in my mind) mostly on the semantics of the copy-
ctor/assignment.  In all of my own implementations I've taken the 
easy way out and removed copy functionality, but I'm not going to say 
that this is the best decision... yet.