Thread Pooling

Craig Black cblack at ara.com
Sun Apr 23 15:40:30 PDT 2006


"kris" <foo at bar.com> wrote in message 
news:e2gtv3$1oqh$1 at digitaldaemon.com...
> Craig Black wrote:
>>>I've considered this as well.  In fact, I've got library code to do this 
>>>for C++.  But I'd prefer something a bit more forward-looking for D (see 
>>>Herb Sutter's Concur project for one possibility).  I'm planning to 
>>>address this need at some point in Ares, probably in a manner similar to 
>>>the Concur design, but I don't have time at the moment.
>>
>>
>> I don't see syntax this high-level to be implementable in a library.  It 
>> seems like this would require features to be added to the language core. 
>> Or do you disagree?
>>
>> -Craig
>
> Are you thinking of Occam-style 'par' and 'alt' constructs, or something 
> different?

I don't know anything about "Occam" (Objective caml?) so I can't comment on 
that.  Concur is an experimental research project in search high-level 
language constructs for C++ that provide safe and efficient parallelism.  I 
can give you a brief tutorial but it's probably best look it up on the net.

With Concur language features, there is no more dealing with threads and 
locks.  The first example presented is the notion of an "active" class, 
which is a class where each object instance conceptually runs on its own 
thread.

active class C {
  void foo() { ... }
}

void main()
{
   active C c;
   c.foo(); // call is nonblocking
   ...  // this code can execute in parallel with c.f()
}

There is an issue with return values when calling a method on a separate 
thread.  That is, the method doesn't return until the thread is finished. 
For such return values, Concur introduces the notion of "future" values, or 
values that may or may not be evaluated yet.

active class C {
  int foo() { ... }
}

void bar(int x) { ... }
void bar(future int x) { ... }

void main()
{
   active C c;
   future int result = c.foo();
   bar(result.wait());  // calls bar(int)
   bar(result);            // calls bar(future int)
}

I think "out" parameters in active methods should also be declared "future" 
as well.

(Please anyone correct me if I am misinterpreting any of Herb Sutter's 
stuff.)

There are some other ideas presented as well ... but like I said you can 
look it up on the web.

-Craig 





More information about the Digitalmars-d mailing list