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