Re: The world needs process-orientation

[Claude Petitpierre <claude.petitpierre@xxxxxxx>]

Bonjour,

I enjoyed the discussions about x-CSP very much.

Background
Actually, I have used multi-tasking in a cement plant more than 30 years 
ago. I have developed a CSP version of C++ (IEEE computer Sept 98) and 
adapted it to Java (CPA02 and CPA03). And I have always been 
frustrated by reviewers of papers I tried to place outside the 
CSP-converted world, because they did not see the purpose of CSP-like 
approaches beyond its use as a theoretical language for analysing toy 
programs. Moreover, they always had their preferred way to solve the 
communication problems I was presenting.

One step forward
In order to understand how to introduce multi-threading in industrial 
projects, I embarked upon a survey of the tools available to develop Web 
based applications: databases, Java libraries (GUI, listeners, J2EE, 
JSP, Struts), JBoss, Eclipse, and ended up with a book 
(http://www.epflpress.org/Book_Pages/petitpierre.html) and a language 
(http://ltiwww.epfl.ch/WebLang), with which one can describe a Web 
application quite easily.

Why CSP is not appealing
While doing that, I realised that however essential the multi-threaded 
aspects are, most of the time they only represent a very small part of 
any application. This part is designed by specialists - who should 
indeed know about CSP - and distributed under the form of a middleware 
(J2EE, .Net&). On the other hand, solutions often appeal to developers 
by their complexity and the involvement of heavy tools (see the number 
of XML files that are required to start JBoss). Thus, nobody cares about 
a simple tool that solves a small part of an application!

Where to go
As somebody mentioned, if there is a hope to boost the CSP domain, it 
lies on multi-processors. Transputers were a good starting point. They 
showed that hardware is essential to build communicating systems. 
Actually, it would be very timely to study and develop a new set of 
efficient hardware devices adapted to CSP (or CCS). For example, the 
Transputer write statement was asynchronous, to simplify the handling of 
the alt statement in a distributed envieonment. I think it was not a 
good idea, because it does not make it possible to pass a signal only to 
the first ready process of a set, as rendezvous would do (with 
asynchronous channels, one should cancel messages already sent). I would 
like to have selectable (alt) distributed (multi-processor) rendezvous, 
but this is very heavy to build in software. We should have some shared 
memory and possibilities to store and select signals in associative 
memories, in order to establish quick rendezvous requested by several 
processors and to automatically cancel the ones that are not chosen.

Best Regards,

Claude