Re: [boost] [threadpool] new version v12

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

"vicente.botet" <vicente.botet_at_[hidden]> writes:

> ----- Original Message ----- 
> From: "Anthony Williams" <anthony.ajw_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, November 03, 2008 10:25 AM
> Subject: Re: [boost] [threadpool] new version v12
>
>
>> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>>
>>> From: "Anthony Williams" <anthony.ajw_at_[hidden]>
>>>
>>>
>>> For task the same applies; there are some entities(functions, classes,
>>> ..) that are task-safe and others that need some task specific
>>> synchronization tools to ensure task safety.
>>
>> Yes. Unfortunately in some cases the set of functions that are not
>> "task safe" includes particular uses of the standard C library and use
>> of particular C++ constructs in particular ways on some platforms.
>
>> You need to be aware that these things will be replaced if the task is
>> suspended and a new fiber scheduled.
>
> Yes as this is already the case for TSS, we need to recover the TSS
> data on the stack before calling other functions that could modify
> it. We need to take care of this.
>
>> Doubly so if the task is migrated to another physical thread.
>
> I don't think we need to migrate an already started task.

There are scenarios where it's useful. See my other recent posts.

>>This makes it a really bad idea to wait
>> for a future in a catch block, for example.
>
> Sorry I don't see why. Could you describe the issue?

future<T> some_future;

try
{
    throw my_exception();
}catch(...)
{
    some_future.wait(); // may invoke task from pool if some_future
                        // not ready
    throw; // oops, where's my exception state gone?
}

>>> * The second question if we use this kind of framework is how can we
>>> make task-unsafe entities task-safe using some kind of synchronization
>>> or specific context at the task level.
>>
>> In the general case, I don't think we can. However, we can do things
>> to mitigate the problem. For example if the thread pool collaborated
>> with boost::thread, it could switch the thread data so you had a
>> different thread::id value, and thread_specific_ptr values were local
>> to the task.

>> This doesn't help with locks or thread-specific data
>> taken from outside of boost (e.g. in the CRT), but it does help
>> somewhat.
>
> Are you saying that if we switch the thread data locks will work when
> we use boost::thread? I though that mutex are associated to the
> underlying OS thread.

No. I was saying that switching boost TSS data doesn't help with
locks. It also doesn't help with TSS data from the CRT.

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