"vicente.botet" <vicente.botet@wanadoo.fr> writes:
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Monday, November 03, 2008 10:25 AM Subject: Re: [boost] [threadpool] new version v12
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
From: "Anthony Williams" <anthony.ajw@gmail.com>
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