RE: OO vs. CSP - Papers, Arguments?

["Kerridge, Jon" <J.Kerridge@xxxxxxxxxxxx>]

I gav a paper on Groovy parallel at CPA2005, which is a set of simple
constructs written in Groovy.  Groovy is a scripting language sitting on
top of the java platform.  It integrates with JCSP to provide ALT PAR
and channel lists in a natural manner.

Jon Kerridge

-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Gerald Hilderink
Sent: 22 September 2005 13:09
To: 'Andrzej Lewandowski'; 'Koehne Kai'; occam-com@xxxxxxxxxx
Subject: RE: OO vs. CSP - Papers, Arguments?

JCSP and CTJ are limited to Java. Java was designed to leave many things
up
to the user. At least JCSP and CTJ provide proper guidance for building
safer concurrent software.
One simple guideline is that the user must obey the ownership rule
(aliases
must be avoided) when sending object references across channels. Java
does
not check this rule, but the programmer can apply this rule during
programming. This is not hard, because you only have to check the
producer
processes.
CSP is inherently compositional and does scale up well. Objects are
compositional, but objects+multithreading are poorly compositional. In
other
words, multithreading does not maintain the compositionality of objects.
CSP
does maintain the compositionality of objects along processes.

> CSP is not a silver bullet either. It scales up poorly. Try to
implement
> system with 400 channels (I did) and debug such system. "Spagetti 
> channels" is no fun, and maintaining large systems based on CSP is
pretty 
> hard.

"Spagetti channels" is something I have never experienced. The large
number
of channels was never a big issue. The number of channels does not
necessarily make debugging harder; one does not need to consider all the
channels at ones. A cycle of communications may contain many channels,
but
still this can be analyzed without extensive run-time debugging. Perhaps
it
is more difficult to find the cycles of communication in a complex
design
(spider-web). This tells more about the design or lack of proper tool
support.
CSP allows you to debug complex systems in a systematic way. Every
process
can be tested in isolation. Furthermore, you can add probe channels to
collect the traces of events. This also allows you to observe real-time
behavior (dead-lines between events). Of course, FDR can assist to find
pathological problems.

Systematic debugging is undocumented, is it? Is there a paper that
addressing systematic debugging in CSP-based frameworks? Perhaps this is
an
interesting topic for the CPA-2006. Any volunteers?

BTW CPA-2005 was a great success.

Gerald.

> -----Original Message-----
> From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx]
On
> Behalf Of Andrzej Lewandowski
> Sent: donderdag 22 september 2005 11:52
> To: 'Koehne Kai'; occam-com@xxxxxxxxxx
> Subject: RE: OO vs. CSP - Papers, Arguments?
> 
> All isues regarding "data encapsulation in objects vs. CSP" is no
issue.
> Practical implementations of CSP (such as JCSP) don't provide any
safer
> ancapsulation than plain OO - since JCSP works on references to
objects,
> any abuse is possible and I do whatever I want by using iheritance in
> "creative" way.
> 
> The real problem  with concurrent OO is "inheritance anomaly". This is
> the phenomenon that inheritance from concurrently safe object can
> violate the safety, and concurrently safe objects extended by
> inheritance can be not concurrently safe. This practically eliminates
> inheritance from concurrent objects landscape, what doesn't mean that
> concurrent OO are useless - it is possible to use delegation, that as
I
> know does not create such problem.
> 
> See the following papers:
> 
> http://citeseer.ist.psu.edu/matsuoka93analysis.html
> http://people.cs.vt.edu/~kafura/PreviousPapers/coop-isipcala93.pdf
> 
> More you will find on Yonezawa page (Yonezawa published 2 books on OO
> concurrent programming, walk to the library)
> 
> http://web.yl.is.s.u-tokyo.ac.jp/
> 
> Check implementation of actors paradigm for Smalltalk by Briot. Look
on
> his publications, you will find a lot about objects/concurrency
> 
> http://www-poleia.lip6.fr/~briot/publications/publications.html
> 
> CSP is not a silver bullet either. It scales up poorly. Try to
implement
> system with 400 channels (I did) and debug such system. "Spagetti
> channels" is no fun, and maintaining large systems based on CSP is
> pretty hard.
> 
> 
> A.L.
> 
> 
> > -----Original Message-----
> > From: owner-occam-com@xxxxxxxxxx
> > [mailto:owner-occam-com@xxxxxxxxxx] On Behalf Of Koehne Kai
> > Sent: Wednesday, September 21, 2005 3:47 AM
> > To: occam-com@xxxxxxxxxx
> > Subject: OO vs. CSP - Papers, Arguments?
> >
> >
> > Hi,
> >
> > I am just starting to work on my master thesis that aims to
> > extend Occam to become a useful coordination language for
> > Grid Computing. I already read a lot about CSP, Occam and
> > diverse extensions of it. However, I think that I am still
> > missing answers to an important question: What are the main
> > advantages/disadvantages of the CSP approach in contrast to
> > concurrent object oriented aproaches?
> >
> > My perception is that CSP just feels more "natural" when it
> > comes to concurrent programming, but I am sure that there are
> > a lot more sound and sophisticated opinions on this topic
> > 'out there'. The only reasoning I am aware of is in a
> > presentation of Peter Welch called "Communicating Processes,
> > Components and Scaleable Systems" where he states that OO is
> > not providing "real" data encapsulation. I would be very
> > grateful if you could provide me hints on further comparisons ...
> >
> > Regards and thanks in advance,
> >
> > Kai Koehne
> > Hasso-Plattner-Institute
> > University of Potsdam, Germany
> >
> >
> 
> 




This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
University's system is subject to routine monitoring and filtering by the University.