Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-04-19 10:48:40

Hi Cristophe,

> Hello,
> regarding thread local storage we have come up with a different
> perspective of the problem.
> First we where not very happy with boost threads because it requires a
> copy of the functor object. This does not allow to put non copyable
> object as member variables of the functor object. Knowing that mutex
> are none

that's not a problem. You can always put a non-copyable object inside a
struct and pass a smart_pointer to that struct.

> We chose the start&run model used in many thread API because it allows
> to initialize the thread object before it is started and collect
> result after the thread terminated.

same can happen with current [thread] library.

> The thread object is the obvious place to use as thread local storage.
> This is because stored data is explicitely defined and its use is
> statically checked. It is also automatically destroyed with the thread
> object is destroyed.

are you sure? what if the thread is ::Terminated?

> Thread objects are dynamically allocated and referenced through
> intrusive pointer. Thus thread objects can have

same could be achieved with smart pointers.

> In the thread local storage managed by the system/pthread we only
> store a pointer to the thread object. This is to allow to get access
> to the thread object from anywhere in the code. This is equivalent of
> the this variable for objects but for threads. Thus the thread class
> has a static self() method returning a reference on the current thread
> object.
the self() is a pretty good idea. However, the big issue is not when
[thread] is used within a custom application, where you know exactly
what TSS data you need. The issue is when you develop a library that
depends on [thread] and needs TSS.

> It also to be noted that boost thread implementation would start the
> thread before the boost thread object instantiation would complete.
> Such constrains should not be imposed to the users. There is thus a
> need to know

I'm not sure I follow. Could you please give an example?

> Regarding synhcronization we have also made a slight move away from
> boost API which was aslo the best seen so far. We make a distinction
> between locks and latch.
> A lock has no method. When it is constructed it immediately attempts
> to lock the mutex, and the destructor release the mutex. Thus when a
> lock is instantiated, the mutex can be assumed to be locked by the
> thread who performed the instantiation on its call stack.
> When a latch is instantiated, the mutex is not locked. The following
> methods lock, unlock, try_lock and timed_lock are used to control the
> referenced mutex. When a latch variable is destroyed it automatically
> unlock the mutex if it was currently locking it.
I don't think this has bought you anything. In fact, I think it's more
prone to error, since who's stopping you to do:

void crazy() {
some_lock l(mutex);

> We believe there was a possible confusion in the initial lock state of
> boost locks. It is not orthogonal.

Again, could you give an example?


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