[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.