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.