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

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-07 07:20:15

Hi,

--- John Panzer <jpanzer_at_[hidden]> wrote:
> I work with multithreaded servers written in C and C++, primarily
> with various pthreads implentations.  Lack of multithread safety* in
> third-party libraries is a big obstacle, and having a standard
> interface for avoiding race conditions would help here.

I definitely agree with this! One reason for me getting involved into
this to work out such an interface and, in the next step, integrate my
standard library implementation with this. Bringing it forward even a
step further, I want to actively support a corresponding proposal for
the C++ standard: Without support from the compiler and the standard
C++ library basically all multi threading safety is moot! Two examples
of show stoppers are exceptions (what happens when two exceptions are
thrown simultaneously in two different threads; the answer that there
are distinct stacks for the threads does not mean anything since the
exception being thrown is not allocated on the stack and an
implementation might very well allocate just one area of memory for the
one exception which can be thrown at any time) and memory allocations
(because there is just one globale resource maintaining the heap
allocated memory).

> A standard interface with something as low-level as a pthreads-style
> non-recursive mutex, augmented with a standard mutex lock class to
> automate unlocking, would be useful and worthwhile.  Not that I'm
> arguing for this as the interface, just saying that it would be far
> better than nothing.

Given just the few suggestions for techniques I have made, I think the
interface for a mutex also needs the ability to have a non-blocking
lock method: If locking was successful would be determined after the
lock attempt. I agree, however, that the fundamental mutex should be
non-recursive because there are techniques where it is not necessary to
have recursive locking and I guess (but haven't measured it) that there
is a performance penelaty. Also, if an ID for the current thread can be
obtained somehow it is possible to create a recursive lock using these
two facilities. This is something which should probably be documented
on the pages, too.

> On the separate topic of thread manipulation, it would be nice to be
> able to write code that uses threads in a standard and portable way. 
> If a standard interface provided only the following, it would be
> useful:
> - A way to create a thread, passing in arbitrary data in a type-safe
>   way.
> - A way to to end the current thread, analogous to exit() for the
>   process.
> - A way to get some unique identifier for the current thread.

Despite what I have said before and what is currently said on the pages
I agree with this: To built higher level tools on the basis of low
level tools like eg. a basic non-recursive mutex it is necessary to
have some interaction possibilities with a thread. Basically, it is
useful to have a thread ID and the possibility to associate data with
a thread. Whether and ID together with a map provides the same facility
as associating data with a thread is somewhat unclear to me: It would
be necessary to lock the map while otherwise thread local data can be
used, at least from within the current thread. I can't tell whether 
this would be sufficient.

> (Killing an arbitrary thread is IMHO a bad idea, since it almost by
> definition leaves the program in an undefined state.

I think that the typical situations for killing a thread are better
dealt with using execptions.

> I'd be happy to try to write up something less vague if there is any
> interest.

I think this would be useful.

=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/