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?