OSNews

Not one person has mentioned CSP, or occam family of parallel languages. Ironically the father of CSP Sir Tony Hoare actually works for Microsoft Reseach in Cambridge and I guess he isn't making much impact on his employer.

Those who work with these languages have no or few problems with conccurency at the language level since CSP is a mathematical model for concurency. And it was also well demonstrated on the Transputer some 20yrs ago on larger clusters and continues to work well enough in x86 & others but AFAIK mostly in single cpus today.

Ironically as a HW engineer I see occam as a hardware like language, since processes describe entities that could be hardware or software. Either way processes are wired up together in a hierarchy just same as hardware modules are. But these par processes can just as well include sequential processes, ie par & seq are treated as equals although par blocks obviously add some overhead and could use some hardware help which is unlikely in current processor designs. That help includes built in message passing support, and an event, process scheduler in hardware.

Also the hardware EEs use concurrent languages all the time, Verilog is based on a mishmash of previous language syntaxes but has C,APL expression and Pascal block level. VHDL draws more from ADA,Pascal.

Since I need a new compiler for a new Transputer and occam syntax is very unlike C, I propose to use C++ classes with processes.

As struct => classes by adding methods to data, the obvious step is to add concurrency to classes by adding ports that are live. Actually it looks alot like Verilog but fully C syntax. Such a language can then easily do what occam could do as well as run massively concurrent programs. In order to write such programs, one would have to wear a hardware hat in decomposing larger processes into smaller ones and then wire them up. But if the processes really are hardware like, they can also be translated back into pure Verilog and synthesized into real hardware. So classes with live port lists can be used for both parallel software and hardware design.

struct sname { int a,bc....

class cname ( int a,b,c... cname(); .. void fn() etc

process pname1 ( in i, out x, event e, int a,...)
( int a,b,c... cname(); .. void fn() etc
// usual C++ stuff, declarations, methods

wire w,x, // hardware wires from Verilog
chan ch1, ch2... // software wires from occam

l2: pname2(p, q, ,foo); instance of 1st process
l3: pname2(foo, y,, ); instance of 2nd process
// instances can't be recursive though

}

As for Java,C#, their thread models are totally broken, and Java 1.5 only recently attempted to reduce the damage by looking at CSP for more inspiration. Ironically the Java designers knew damn well all about CSP when designing the Java thread model but went for something much older and far less capable. They thought CSP was tooo complicated for software engineers, yet when its implemented properly, its way easier to fathom decomposition of process than these thread objects.

sorry for long thread

transputer guy
aka John Jakson