Re: Threads: what I wrote...

From: Gernot Neppert (gn_at_[hidden])
Date: 2000-08-09 05:26:52

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

>>[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?