Re: [boost] [stratified] library for micro-/userland-threads

Subject: Re: [boost] [stratified] library for micro-/userland-threads
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-07-02 07:33:34

On 07/02/2012 01:13 PM, Oliver Kowalke wrote:
>> Just a few comments from a first glimpse at the library:
>>      - It is not really thread safe (for example the static scheduler
>> initialization and the spawning of new stratums)
> you missunderstood for what boost.stratified was intended for.
> a stratum is a userland-thread which means it runs during its live-time only in one thread - cooperativly scheduled. you can not migrated a stratum between threads.
Then the docs are misleading, and see below.
>
>
>>      - It would be nice if the whole scheduling of stratums would be more
>> transparent and configurable to for example deal with different multicore
>>        architectures.
> see above - it runs only on one core, in one thread.
>
>>      - Lightweight synchronization primitives are missing
> what about the mutex, condition- and event-variables? the objects in boost.stratified use context switching (boost.context) which consumes ca. 40 CPU cylces.
Ok, i missed those. Sorry about the noise ...
>
>> And now for the shameless plug ... if you are looking for something that
>> does all this, you might want to take a look at HPX
>> (http://stellar.cct.lsu.edu)
> Yes, I know the work on HPX, but it is intended for other purposes.
Well, as it stands, stratified is a clear subset of the HPX 
capabilities. That was the only reason i mentioned it.
>
> boost.stratified as well as boost.context is a derived from my previous library - boost.task (started in 2006/2007 as boost.defere/boost.threadpool etc.).
> Because I was ask to provide the implementation details regarding to context switching/userland-threads (used inside a threadpool ->  work stealing) as separate libraries, I refactored the code and boost.context/boost.stratified are the results.
Sure, makes sense. However, this is a bit conflicting to what you said 
above (should only run in one thread vs. usage inside a threadpool with 
work stealing).
I understand that user level threads are orthogonal to os level threads. 
However, i doubt the usefulness of the library if it is only usable from 
a single thread. Multicore systems aren't going away, and from my 
experience, the true power of user land threads is unleashed when indeed 
doing work stealing over multiple OS level threads, as you already 
mentioned.
>> It has all the features described above and more (for example support
>> for distributed memory machines through a global address space).
> boost.stratifed does not focus on the features of HPX.
>
>> P.S.: the code in the archive doesn't compile for me (boost trunk, gcc
>> 4.7 and intel 13 beta)
> was tested with boost 1.49 only - but the  archive is updated and should work now
>
> best regards,
> Oliver
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost