Functional Muti-threading

[janderson]

Here's one idea about how D could help support multi-threading.  What if 
you could specify which functions where thread-able.  ie:

threadable int foo(int X)
{
...
}

void bar()
{
    int a = 0;
    int array[3];
    x[0] = foo(a);  //Separate worker thread
    x[1] = foo(a);  //Separate worker thread (or could be main thread)
    x[2] = foo(a);  //Main thread
    //Would sleep here until things are done
}

Say foo was a relativity small function.  The compiler may decide to 
pack 2 thread operations together for greater efficiency.  The compiler 
would have the ultimate decision about when something gets placed on 
another thread.  Whether an application is compiled threaded or not 
would be a compiler flag (-threaded).

The compiler should also be able to determine functions that can be 
threaded saftly and add these to the list (kinda like how inline works 
in C++ -> you can mark something as inline to let the compiler know but 
it also makes its own decisions).

Consider the for loop:

int array = new int[];
array.length = GetSize();
for (int n=0; n<array.length; ++n)
{
    array[0] = foo(4);
}
//Sleep until finished

In this particular case the compiler knows at runtime what the size is 
just before the loop starts (and size does not change).  It could divide 
the work into the number of hardware threads.

Consider the for loop:

int array[] = new int[];
for (int n=0; n<GetSize(); ++n)
{
    array ~= foo(4);
}
//Sleep until finished

In this case the compiler has no-idea about how many times the loop will 
run.  It would have to hand out the tasks for foo one at a time to 
whatever worker thread were least busy.

Another thought for the for loop was to do something like:

int array[] = new int[];
Threadable(4) for (int n=0; n<GetSize(); ++n)
{
    array ~= foo(4);
}

Where threadable(4) tells the compiler that the work should be served 
out in lots of 4.  It could compile 4 versions of of the function (ie 
one with 4 foos, one with 3, one with 2 and one with 1).

Because these optimisation could get really complex, I think you'd start 
by just allowing the threadable option and then slowly add optimizations 
to support it.

The downside to this approach is that you would probably not be able to 
get the performance a of hand tuned threading application.  But then 
again, that would take a lot longer to write.

Anyways the point is, the compiler would decide when to do 
multithreading and what threadable functions can be compounded together 
at compile time to make for an optimal program.

Just a ruff idea.  I think compiler support for multi-threading in some 
form would be helpful in D's success.

What do you think?