Re: [boost] Cooperative Multi-Tasking

Subject: Re: [boost] Cooperative Multi-Tasking
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2010-03-07 21:51:39

On Mar 7, 2010, at 2:47 AM, Chris M. Thomasson wrote:

> "Daniel Larimer" <dlarimer_at_[hidden]> wrote in message news:A46E676B-59BA-4117-879E-7FE391255B21_at_gmail.com...
> [...]
>> Talking with my employer, I am gaining support for eventually open sourcing a lot of this!   As far > as I have been able to google, I have not found any system that does what I describe above.
> 
> I take it that you are not familiar with Clik++:
> 
> http://software.intel.com/en-us/articles/intel-cilk
> 
> 
> or QuickThreads:
> 
> http://www.quickthreadprogramming.com
> 

Nope.  And I searched just about everything I could think of to describe corporative multi-tasking and user threads.  Found lots of stuff, but not those.

The intel library looks interesting in that it is the most cross platform, where as quickthreadprogramming.com mentions Windows 7 but says nothing about linux/g++. 

As nice as those libraries are, they still fail to achieve my desired syntax:

struct SomeServantClass
{
        int width();
        int height();
        int calculate_area(int w, int h);
};

IDL_STUB( SomeServantClass, IDL_BASE,
        METHOD(width), 
        METHOD(height),
        METHOD(calculate_area)
)

actor<SomeServantClass>     a;

future<int>    w            = a.width();
future<int>   	h  	       = a.height();
future<int>     area      = a.calculate_area( w, h );
future<int>     area34 = a.calculate_area( 3, 4 );

Where the tasks are all "automatic" and under the hood.  SomeServantClass could be ANY existing class without modification.  Also, area34 would be realized before area because w and h must be evaluated before the first calculate_area can be scheduled, where as the second can be scheduled immediately instead of weight on other futures.

I suppose I could build my scheduler / active objects system upon one of those libraries.  Boost.task looks the most promising from what I have seen.     

I guess for what I am doing, these higher level task abstractions attempt to do "too much" and I would essentially be using them as an implementation of coroutines.   I don't want my users to be thinking about threads, locks, wait conditions, yielding, scheduling, etc.  I want them to operate on a much higher level.