On 7/1/2012 4:23 PM, Julien Nitard wrote:

HI Oliver, all,

...

source: http://olk.bplaced.net/boost-stratified.zip documentation: http://olk.bplaced.net/boost/libs/stratified/doc/html/

It may be due to my location, but I guess an error on both links. Is it working fine for other people ?

Works for me. -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Mon, Jul 2, 2012 at 9:58 AM, Julien Nitard <julien.nitard@m4tp.org>wrote:

I've tried Chrome and IE (just in case) and same problem: 403 (and an Ad for good measure) with a link to bplaced.net (which works). I guess the hosting company has blacklisted my work ISP for some reason ... I'll try from home (much) later.

Same here, but I'm in Japan, so I don't think it is blacklisting. The www.bplaced.net link don't work for me, the same error in german. Joel Lamotte

...

I've tried Chrome and IE (just in case) and same problem: 403 (and an Ad for good measure) with a link to bplaced.net (which works). I guess the hosting company has blacklisted my work ISP for some reason ... I'll try from home (much) later.

Same here, but I'm in Japan, so I don't think it is blacklisting. The www.bplaced.net link don't work for me, the same error in german.

strange - access from Germany works for me?! I'll ask the hoster for this issue. regards, Oliver

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

On Tue, Jul 03, 2012 at 08:16:53AM +0200, Oliver Kowalke wrote:

...

Perhaps it's too late to suggest this, but could the library be given a more meaningful name than "stratified"? Perhaps "fiber" as that's what's being implemented?

fiber (Windows specific) - was one of its previous names like:

fiber, strand, stratified, tasklet, ...

I'm not sure which name would fit better.

Please do not use 'strand'. It's an existing different concept in Asio which will majorly confuse any user if you go with it. I'd recommend 'fiber', not getting stuck up on platform specific names. After all, you've got things like the Windows mutexes which are IPC primitives, while the 'mutex' in Boost.Thread is intra-process. I'm opposed to the "Stratified" and "stratum" names, as they do not really mean anything relevant, and as far as I know, have never been used in literature to mean user-level threading. -- Lars Viklund | zao@acc.umu.se

On 07/03/2012 09:50 AM, Oliver Kowalke wrote:

...

Please do not use 'strand'. It's an existing different concept in Asio which will majorly confuse any user if you go with it. OK

...

I'd recommend 'fiber', not getting stuck up on platform specific names. After all, you've got things like the Windows mutexes which are IPC primitives, while the 'mutex' in Boost.Thread is intra-process. hmm - boost.stratified does not contain IPC primitives - mutext, conditon_variable, ... use only context swapping (from boost.context). the kernel is never involved.

what boost.stratified tries to solve is:

- cooperativly schedule strata (a stratum is more or less equivalent to a coroutine)

- provide synch. primitives to coordinate communication/access between strata (same as synch. primitives do in boost.thread) Just for clarification, how is stratified related to your proposed coroutine library?

...

I'm opposed to the "Stratified" and "stratum" names, as they do not really mean anything relevant, and as far as I know, have never been used in literature to mean user-level threading. the name was used in order to refer to 'Stratified JavaScript' http://onilabs.com/stratifiedjs.

regards, Oliver

_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Just for clarification, how is stratified related to your proposed coroutine library?

Some additional notes: I would use a coroutine in order problems related to multiple enter/leave of functions and preserving state of local data. I've added some examples in coroutine/example directory (for instance fringe problem). Nat Goodspeed has showed a good example how a coroutine could be used in its C++ Now! 2012 paper. A stratum/fiber could be used for sub-tasks in threadpools. In order to solve the split-and-join problem, boost.task transforms sub-taks into stra/fibers and let them cooperativly sheduled and migrated between the threads of the threadpool. In such scenario you usally do not need a coroutine because you pass the arguments if you create the task (whic hwill be passed to the threadpool) and the result is transfered via future (excpetions too). Second you need some synch. primitves to coordinate your sub-tasks. therefore I think coroutines are not the best choise for threadpools (of course you could use coroutines to implement fibers/context swapping, but this is already abstracted by boost.context). With strat/fibers I don't have to pay for coroutine args, returns value and coroutine::self_t. roughly, thats my opinion how coroutines and strata/fibers differ. regards, Oliver

Hi Chris,

...

I know I will be too late with any sensible inputs with a microcontroller.

I think you are not too late - could you explain the issue. regards, Oliver

Hi Oliver. I'm glad to see that you have made such great progress on stratified. My problem is that I simply have no time to look into this until September at the earliest. I would like to deeply embed stratified in the ARM Cortex-M3 on this board: http://www.st.com/internet/evalboard/product/250863.jsp It's a 12 dollar board available world-wide (Digi-Key, Farnell in Deutschland, Conrad, etc.). It even comes with its own JTAG debug interface on-board. I have my cross compiler, GCC 4.7 crossed to --target=arm-none-eabi. I do this kind of thing all the time, just never with boost. So here is my wish-plan: I would probably lose time fumbling around with bjam, because, well, that's what I do. Then I would decide to simply circumvent bjam and include my trunk in the compiler's include path. Thereby, I would extract the assembly files from context that I need. I would build a small reference project (also crossed to x86_64). I would program it in the microcontroller with my JTAG debugger. Then I would get it running. In theory, it's no big deal to build because that's what I've done for much of my professional career. But it's never as easy as it sounds. I would probably need a few weeks of off-and-on effort to really embed these proposed parts of boost. I don't have time for it now. I am sorry. I will, however, try to find time to look at the implementation details and give any feedback I can. Best regards, Chris.