[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OO vs. CSP - Papers, Arguments?
>
> 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 ...
>
Hi Kai,
Part of the data encapsulation problem is that you can have chained
member function calls causing problems. Imagine you have a library
system, where Library is an object (holding links to all its Books),
and Book is an object with a link to its Library. You might get a
situation where you call checkOut() on Book. Book adjust its own
member data accordingly, and notifies the Library. Due to a
misunderstanding in the spec, Library invokes a notification method on
Book, thus checking it out a second time. When Book returns from
notifying the library, it doesn't know that it has been accessed again
during that time; the program would continue and the bug remain
undetected.
In CSP of course, the Book would not have accepted further channel comms
while waiting for the Library to get back to it unless it had explicitly
been coded in that way. The bug would have caused deadlock, and the
problem exposed immediately. Obviously this is a trivial example, but
the principle remains a problem.
Concurrent OO also has the problem that race hazards are very easy to
introduce because the underlying language does not obey CREW and other
such principles. If two parts of an Occam PAR attempt to write to the
same data, it will not compile. If two C++ threads write to the same
data, there will be no obvious problem until the race hazard occurs
during running the code. CSP's strength is that it transforms
insidious concurrent problems such as race hazards into easier
problems; those of deadlock and livelock.
I'm sure others on this list will also have good explanations as well.
Neil.