Re: [boost] Re: Threads: what I wrote...

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-09 09:47:08

In message <8mrp48+9rie_at_[hidden]>, William Kempf <sirwillard_at_my-
deja.com> writes
>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.

I couldn't agree more. Keep threading concrete, and allow anything that
satisfies NullaryFunctionObject requirements to be passed through for
execution.

The trend I've noticed in the discussion of this group is that everyone
is already getting caught up in specific classes, whether one form of
mutex or another should be used, what hierarchies should be modelled,
etc. This is, IMHO, a valid but traditional approach to the problem. I
would have thought (and it is certainly what I now practice) that the
more appealing/natural approach would be from a generic programming
perspective.

In other words, initially drop all the talk of _a_ thread class to the
requirements on Thread (as concept). A first stab suggests that it must
have some kind of generic run function (personally I prefer it to be
called operator()) that takes a NullaryFunctionObject. It should be
default constructible, but not copyable (either by ctor or by
assignment). It should be destructible, and there should be some
mechanism for joining other than a dtor. No kills, pauses, etc as these
are unsafe.

There's clearly more to threading than this, but I would consider this
the core set of requirements that we can probably (hopefully :->) agree
on. Other requirements (such as priority control) can be catered for,
STL-style, by additional sets of requirements. Once we're reasonably
comfortable with that, one or more boost:: thread classes make sense,
but we have also kept the door open to other implementations that
satisfy the base requirements.

The same approach can then be applied to other features, such as
synchronisation primitives, for which we can also provide cross-platform
defaults in the library. I mentioned this in another posting, the idea
of Mutex (or perhaps SynchronizationPrimitive or SynchronizationLock
would be less confusing) requirements, the simplest of which constitutes
Semaphore, then Mutex (or similar), then ReentrantMutex, etc. This would
give us a basic model that can be extended for CountingSemaphore,
ReaderWriterLock, etc.

Orthogonal to these is the idea of scope-bound locking, for which we can
specify normal lock, try lock, timeout locks (?), resource-acquisition
types that are written independently of the actual locking classes (ie
not nested), as well as locking smart pointers.

I personally feel that an STL-like approach will lead to a clear and
loosely coupled set of interfaces, and is the better way to go these
days. It also unasks a number of questions that have been floating
around, such as process vs thread locks (either can be handled), should
unlock be public (yes, because these are primitives and the locker
classes are there to do the right resource management thing), and so on.

With such primitives established, it becomes easier to consider how
classes may be built on top of them, eg monitor-like queues. The MS free
threading and apartment model is interesting, but the UML categories for
concurrency might provide a better starting point for actual safety
definitions (sequential, guarded, concurrent) coupled with the
definitions established to date.

I'm happy to work out a strawman doc based on this idea and building on
Dietmar's definition's doc, if anyone's interested.

Thoughts?
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________