[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The world needs process-orientation


I enjoyed the discussions about x-CSP very much.

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,