Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-27 10:30:52

From: "William Kempf" <williamkempf_at_[hidden]>
> No. Adoption is a QoI issue. However, on most (obviously not all)
> platforms even if there's multiple libraries for MT they are all based on
> level constructs so users expect the various wrappers to work together as
> much as possible. Users will expect to be able to write library code that
> works no matter what MT library someone chooses to use in the application
> that links to it. This is not an unreasonable expectation. So a goal of
> Boost.Threads should be (and is) to make it as easy as possible for
> "adoption" to be implementable. The proposed interface does this.
> works flawlessly for both POSIX and Win32 implementations. The thread_ref
> design, however, can't insure this, and in fact adoption on POSIX has been
> shown to be extremely problematic with this design.

Not 100% correct (AFAICS). This is not an inherent property of a
thread_ref-based design. The "implementation defined" current() means that
several different variations are possible:

1. Fully compliant, current() works as intended no matter what (requires
native support.) This is expected to be the behavior of a quality C++
standard library implementation that cooperates with the native threading
library if there is one.

2. (POSIX-based) current() works as intended provided that pthread_join()
and pthread_detach() are never called on an adopted thread.

3. (POSIX-based) current() works as intended except that an adopted thread
is not joinable; whoever created the thread is responsible for joining or
detaching it.

4. (Win32-based) current() works as intented, except that the thread object
associated with the adopted thread is not guaranteed to persist after the
thread_ref is destroyed. (Unless there's some clever way to implement
cleanup handlers on win32 that I'm missing. A __declspec(thread)+destructor
combo doesn't seem to work. A helper DLL might.)

And of course

5. current() cannot be used to adopts threads.

I should also add that when, in the future, thread cancelation is added to
the library, canceling an adopted thread would likely lead to undefined
behavior -- this applies to both designs. (Unless - again - I'm overlooking
a clever solution to the problem.)

> The complaint is that
> the proposed design makes a thread_ref design difficult to be implemented
> top of it, but my contention is that the issues are nearly identical to
> implementing a thread_ref design on top of POSIX to begin with.

Depends on which variation you have in mind. #2 is possible with pthreads
but not the current Boost.Threads, #3 is possible with both -- except for
the main thread problem with Boost.Threads.

> The one
> difference is a theoretical allowance for the "initial thread", but I find
> it very difficult to distinguish this thread from any other in this

Just to clarify, are you saying that Boost.Threads will never allow users to
join the main thread?

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at