Subject: Re: [boost] Boost.Thread project for GSoC 2014
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-03-07 02:09:53
Le 07/03/14 06:16, Haoyue Wang a Ã©crit :
> Hi Vicente,
> Thanks for your detailed reply. Here is some more background about me.
>> Are you familiar with thread-safe lock based data-structures?
> Yes. I am comfortable with the implementation and usage of thread-safe lock
> based data structures such as queue, stack, list, and map.
Do you have an thread-safe implementation of a map? Which
synchronization mechanism do you use? The ones in Boost.Thread? Can you
send it to me privately?
>> lock-free data structures?
> 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.
>> Which compiler(s) are you using?
> gcc 4.8/Apple LLVM version 5.0
>> Which platform(s)?
> Linux/Mac OS X
>> Do you use already Boost?
> Only a bit.
Do you know how to build on Boost? How to run tests? How to build a
> Following your suggestion, I will proceed to implement a prototype of
> a thread pool having specific queue for each thread that make use
> of the sync_queue in Boost.Thread as part of my proposal. Hopefully,
> it will be in shape next week.
> Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
>> Le 06/03/14 04:06, Haoyue Wang a Ã©crit :
>>> I am Haoyue, a PhD student in geophysics at MIT. I used C++11 to
>>> write parallel finite element codes in my research and had some
>>> coursework on concurrent programming.
>>> Boost is such a powerful and efficient library. I sincerely hope I could
>>> contribute to it this summer and beyond.
>>> I am interested in the standalone GSoC Projects under Boost.Thread.
>>> Particularly, the Work-Stealing-Thread-Pool project is a great one
>>> that I expect to learn a lot from.
>>> I understand that there could be much more to discuss once I have
>>> a preliminary proposal. Here I just want to ask if I am heading in
>>> the right direction.
>>> I think a good point to start is chapter 6, 7, and 9 of the book C++
>>> Concurrency in Action: Practical Multithreading and the Executors
>>> and Schedulers revision 3 from http://www.open-std.org/.
>> Yes, this is a good starting point.
>>> I haven't used Executor before but I am ware of its existence in Java
>>> for a while. Maybe I could go through some Executor and fork/join
>>> Java examples to see how they are used in practice.
>> I don't think this is a good idea. Why not start with the executors
>> included in Boost.Thread library (develop/master branches)
>>> Finally, I will read and understand the executors codes on GitHub.
>> The executors directory included already some executors. One of them the
>> basic_thread_pool is a good starting point. The work-stealing
>> thread_pool could be based on it and the implementation provided in
>> CCIA 9.1.5.
>>> I hope I could put up a good first draft proposal next Monday.
>>> If there is any advice, please let me know.
>> I would need to know more about your background. Are you familiar with
>> thread-safe lock based data-structures? lock-free data structures?
>> Your first proposal should be as complete as possible and you will need
>> to probe that you are knowledgeable of the problem domain, of Boost
>> environment and of C++11.
>> Showing a prototype of a thread pool having specific queue for each
>> thread (See CCIA 9.1.4) that make use of the sync_queue in Boost.Thread
>> would be really nice.
>> Which compiler(s) are you using? Which platform(s)?
>> Do you use already Boost?
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk