Re: [boost] Boost.Thread project for GSoC 2014

Subject: Re: [boost] Boost.Thread project for GSoC 2014
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-03-09 05:23:11

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