On Tue, Nov 4, 2008 at 4:33 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
----- Original Message ----- From: "Giovanni Piero Deretta" <gpderetta@gmail.com> To: <boost@lists.boost.org> Sent: Monday, November 03, 2008 4:21 PM Subject: Re: [boost] [threadpool] new version v12
Not really. Without compiler help (available on VC++ but not on GCC) there is no way out.
See: http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thread...
for an explaination of the problem.
The __thread bug on gcc with -o1 optimization is not enough convincing to me.
There is little to be convinced about. The reality is that, at least on gcc, you cant reliably use TLS if you migrate tasks across threads. Technically it is not a bug because context switching is outside the scope of C++; also, while Posix does not define the interaction between swapcontext and threads (nor won't in the future as swapcontext has been removed from the standard). I do think that preventing that hoisting would have practically zero impact on performance on x86 platforms (using a segment register has negligible performance impact), but It might make some difference on platforms with more limited addressing modes, so I do not think gcc will ever change it (and yes, the problem is known).
Some TSS usage could be more dangerous when the task migrate but not all.
Unfortunately in general the user has no control over it. And compilers are becoming smarter and smarter at compiling (gcc might do whole program optimization soon), so just ignoring the problem and pretend it never happens on real programs is not a solution (better to have restrictive rules than random undebuggable crashes).
Is for this raison that the user must be able to forbid this migration, and otherwise use fibers/continuations specific data instead of thread specific data.
I see little value for fiber specific data. Microsoft had to add it for very practical reasons (i.e. avoiding rewriting hundreds of thousands of lines of code). As long as you do not expect thread local data to persist across a context switch (or any function whose behavior you do not know), which is always a good thing to do, fiber local data adds nothting to it (except wasting lots of memory). The biggest problem, of course, is that FLS is windows specific (i.e. even if we implemented it in boost, it would be useless if the CRT didn't make use of it).
Of course the locking issue is a real problem. Is for this reason that I think that either for coroutines or fibers we need to explore different synchronization mechanisms and discourage the use of synchronization at the thread level.
For cooperative multitasking you never need synchronization between fibers on the same thread (A scoped guard that asserts that the fiber is never scheduled away in a critical region would be useful though). But hoping to get away from mutexes in general is IMVHO wishful thinking. -- gpd