2017-09-14 6:12 GMT+02:00 DePizzottri via Boost-users <boost-users@lists.boost.org>:
Boost - Users mailing list wrote
> On 14/09/2017 03:03, DePizzottri via Boost-users wrote:
>> I realized that pooled_fixed_stack is not thread safe. Now the question
>> is
>> how to make pooled_fixed_stack mutithread safe?
>
> Fibers are usually bound to a single thread each; can't you just use a
> separate stack instance for each thread?
>
> _______________________________________________
> Boost-users mailing list

> Boost-users@.boost

> https://lists.boost.org/mailman/listinfo.cgi/boost-users

Yes, i tried to instantiate pfs as thread_local inside fiber routine that
spawns other fibers:

thread_local bf::pooled_fixedsize_stack salloc{ 2 *
bf::pooled_fixedsize_stack::traits_type::page_size() };

crashes become rare, but did not completely disappear.

I thought that allocate call to stack allocator appears only at fiber
creation time inside parent's body, but it seems to be there is exists some
other conditions that cause race.

each fiber has its own stack (provided by the stack allocator)
a fiber can only migrated between threads if it is in the suspended state
the skynet_stealing_xyz.cpp does work-stealing (ready fibers are migrated between threads) - if you apply 'thread_local' to stack_allocator
you will end up in a race if the fiber was migrated to another thread and tries to release its stack.
the allocator has to be protected by a lock or you use a lockless algorithm
BTW, the memory allocator used by your libc usually does already cache the memory (depends on the algorithm
and chunk size)