Thread Pooling

kris foo at bar.com
Sun Apr 23 20:55:20 PDT 2006


Sean Kelly wrote:
> kris wrote:
> 
>>
>> Reading the PARC slides, Concur looks quite like a rehash of Occam 
>> constructs? Sutter talks about the FIFO approach to method invocation 
>> (via message passing), whereas Occam/transputer used "channels" for 
>> such things -- including "future" values and so on -- all backed in 
>> hardware (with the physical channels looking more than a bit like the 
>> multi-hypertransport busses of today). As you can see from the above 
>> links, PAR and ALT provided for efficient and granular control over 
>> concurrency.
>>
>> Occam is long since dead, but the ideas and implementation were 
>> ground-breaking. Certainly worthy of a look in this regard?

[I should have said "dead with respect to mainstream adoption"]

> 
> 
> Definately.  As I mentioned in my other reply, I think Concur is a step 
> in the right direction, but merely a step.  Still, it beats the 
> traditional approach :-)
> 
>> And, I agree completely -- it would be awesome if D were to excel in 
>> this arena; perhaps the biggest sea-change in programming strategy 
>> we're likely to see. Any language that can ride that wave will garner 
>> a whole lot of attention :)
> 
> 
> Definately.
> 
> 
> Sean

Since Occam is probably unknown to most, here's a mini tutorial linky: 
http://frmb.org/occtutor.html

The syntax will make some folks barf and chunder, but try to get beyond 
that :)

Most importantly, the language is an implementation of CSP. This means 
the code is mechanically provable as "correct" in terms of its 
concurrency: race conditions, alias avoidance, and various other 
nasties. This is in stark contrast to C style languages.

Notice that occam had array-slices (long ago <g>), and take a look at 
how simple the classic concurrent producer/consumer example is (search 
for the text "going parallel" in the above link).

A fully concurrent OS project is described over here: 
http://www.cs.kent.ac.uk/projects/ofa/kroc/rmox03.pdf , which makes some 
interesting comments with respect to CSP versus traditional (difficult) 
concurrency.

I hope Walter takes the time to read both of these. The ideas have been 
in use since the late 70's, so they're fairly refined at this point. 
Besides, provably-correct concurrency is surely a perfect partner for DbC :)



More information about the Digitalmars-d mailing list