Le 09/03/14 00:58, Tim Blechmann a écrit :
No. But I can learn <atomic> quickly. Is lock-free data structures going to be used a lot for this project? The work-stealing thread pool would have less contention if we use a lock-free dequeue. Of course, we can use Boost.LockFree if it provides already whatever we need. actually, there are work-stealing queue data structures, with private 'push'/'pop' and a public 'steal' function. i do have a prototype of a textbook-implementation from herlihy/shavit, which is pretty efficient, although it is bounded (the maximum number of elements has to be defined in advance) and optimistic (under certain conditions a 'steal' operation may fail). Thanks Tim for the info. I have not yet analyzed how a thread_pool could work with bounded queues. Do we want to block when the queue is full? blocking is probably not a good idea, but one could use a global dynamically-sized queue for jobs if the local work-stealing queue is full. one might loose some properties regarding lock-freedom, though that is not necessarily a porblem ...
it would make sense to integrate such a data structure into boost.lockfree as part of a GSOC regarding a work-stealing thread-pool.
If we found a consensus on what to do when the queue is full, yes this can be done during the GSoC project. that would be wonderful!
Tim, would you like to co-mentor this project? The tricky part of this project is more on the implementation off lock free deque. I would take care of the work-stealing thread pool of course. Best, Vicente