Re: [boost] Re: [thread] again

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);
l.lock();
}

> 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?

Best,
John