On Tue, Mar 5, 2019 at 5:38 PM Manuel Pöter <man...@manuel-poeter.at> wrote: > > After reading the code more thoroughly I've realized that you have some > operations that the Chase-Lev work-stealing deque does not support, like > PushBack or PopBackHalf (although Hendler and Shavit proposed a variation of > the Arora work-stealing deque that supports stealing ~half the entries). > FWIW: for those you are interested - my Xenium library contains an > implementation of the Chase-Lev work-stealing deque: > https://github.com/mpoeter/xenium/blob/master/xenium/chase_work_stealing_deque.hpp
Hi Manuel, Yes, stealing half, pushing from the other side, storing functions by value, moving functions were the reasons. std::function may allocate itself, but if you allocate std::function as well, that's 2 allocations, right? Or you need to rework whole Eigen and TensorFlow to allocate your special pointer-sized thing. And good std::function impls don't allocate in common case. So that makes it completely dynamic-allocation free. And the free will frequently be remote, and there is no magic in memory allocator, it will need to queue it back or something. These are things that authors of most lock-free papers prefer to not mention ;) Also in my design owner and remote threads operate on different data (owner don't touch back, remote don't touch front), I know that front/back are collocated (don't remember why) but they can be made spread completely and work independently. -- --- You received this message because you are subscribed to the Google Groups "Scalable Synchronization Algorithms" group. To unsubscribe from this group and stop receiving emails from it, send an email to lock-free+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/CAEeQi3uRYrq2cYDh_aLM7GuCho0KBFJWfPnqZ6JtN%2B2%2B5sarBA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
