Re: [Boost-users] [fiber] pooled_fixedsize_stack

Subject: Re: [Boost-users] [fiber] pooled_fixedsize_stack
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2017-09-14 06:13:47

2017-09-14 6:12 GMT+02:00 DePizzottri via Boost-users <
boost-users_at_[hidden]>:

> 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_at_.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)