|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk