Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-11-04 10:58:32

On Tue, Nov 4, 2008 at 4:33 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:
> ----- Original Message ----- From: "Giovanni Piero Deretta"
> <gpderetta_at_[hidden]>
> To: <boost_at_[hidden]>
> 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.html
>>
>> 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