Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-11-03 04:37:25

"Oliver Kowalke" <k-oli_at_[hidden]> writes:

>> Fibers are still tied to a particular thread, so thread-local
>> variables and boost::this_thread::get_id() still return the same value
>> for a nested task. This means that a task that calls future::get()
>> might find that its thread-local variables have been overwritten by a
>> nested task when it resumes. It also means that any data structures
>> keyed by the thread::id may have been altered. Finally, the nested
>> task inherits all the locks of the parent, so it may deadlock if it
>> tries to lock the same mutexes (rather than just block if it is
>> running on a separate thread).
>
> OK - yes.

> If the fibers are not moved to other worker-threads this shouldn't
> be an issue - right?

No. The problem is if I am a task running on a worker thread, and I
call future::get(), if another task/fiber gets scheduled on my thread
then it inherits my locks, thread-local variables and thread ID.

Also, I just remembered that on Windows prior to Vista, SwitchToFiber
will not preserve floating-point registers and state. On Vista, you
have to specify FIBER_FLAG_FLOAT_SWITCH in the CreateFiberEx call in
order to enable this. I don't know how much of a problem that is in
practice.

> I read in some news-groups that at least on POSIX platforms the
> interaction between fibers and threads is not defined - maybe the
> post was related to the thread-specific stuff.

I don't know much about fibers on POSIX.

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK