saturn.cs.uml.edu(18)> vi javaCSP
"javaCSP" 155 lines, 7928 characters
From owner-cs1obj-l@LISTS.PSU.EDU Sun Feb 22 14:59:04 1998
Sender: Teaching and Learning Object Technology in the First Year <CS1OBJ-L@LISTS.PSU.EDU>
From: Joseph Bergin <berginf@PACE.EDU>
Subject: Re: Java Collection Proposal.
RJLRf: $PH\06f522\Bergin_DougLeaDBDE.mht
What follows is the history of an exchange between Doug Lea and myself,
with my latest thoughts interspersed throughout.
>From: Doug Lea <dl@ALTAIR.CS.OSWEGO.EDU>
>Date: Wed, 28 Jan 1998 07:43:32 -0500
>To: CS1OBJ-L@LISTS.PSU.EDU
>Subject: Re: Java Collection Proposal.
>
>(Sorry for the delay in replying. Also, sorry if I appear overly
>argumentative.)
>
> >(Lea) This mirrors what happened with me as well as javasoft 1.2
> > collections developers: At first you think that there ought to be a
> > reasonable way of using interfaces in the normal fashion, then settle
> > for tagging, and finally drop the tags! The main problem with tagging
> > is that some collections change their characteristics dynamically. For
> > example those that start off mutable, but then are frozen into
> > immutability. So tags don't work. Even dynamic tag attributes don't
> > work out well. In a concurrent world, you might ask a collection if it is
> > mutable, get a positive answer, and then have someone else freeze it
> > into immutability before you have a chance to try to add something!
>
> (Bergin) I disagree that this example threatens the concept. In a concurrent world, the
> developer would know that executing two atomic methods sequentially (asking
> about mutability and then mutating) is not thread safe. The object would have
> to be locked throughout the sequence.
>
>
>(Lea) But this clashes with the best concurrent OO programming practices: To
>make each object responsible for its own concurrency control.
>`External' client-side locking in concurrent OOP is fraught with
>problems. For example, if I build a Collection class with a fancy list
>implementation that allowed concurrent modifications to different
>parts of the list via fine-grained internal locking, then clients
>cannot ensure sequence atomicity just via a synchronized(list) { ... }
>block. (Aside: for such reasons, it's about time to banish the
>synchronized block statement.) If such collections do need/want to
>support client-side control, they must define explicit transactional
>methods (begin/abort/commit).
(Bergin) If the language is going to be fooled with, then move to
CSP/Message Passing over monitors as the concurrency mechanism. Even
Dijkstra, who helped develop monitors, believes that they are too low level a concept.
>(Lea) Short of requiring such heavy solutions,
>I still think the most reasonable way to accommodate transient
>properties is the current solution: Have the object report that it
>cannot perform the operation by throwing an exception. (Another
>aside: One reason that the 1.2 implementations are by default not
>synchronized is to allow people to layer on different styles of concurrency control.)
(Bergin) I am worried about this for two reasons. First, it seems like
the 1% problem is driving the solution. This is ok, except that it makes
the 99% problem impossible to solve. If collections can't be used to
support algorithm development they are quite useless.
Second is just as serious. If the "best concurrent oo programming
practice requires that each object is responsible for its own concurrency
control", then we are in trouble when it comes to general purpose
collections supporting algorithm development. While I agree with this
goal, it seems to require that all algorithms be implemented behind the
abstraction boundary. This implies that whenever we need a new algorithm
to manipulate a vector (say) we need to implement it within the class
implementing the vector and not outside. This seems to me to be an
impossible requirement in large software projects. No class or even
interface (perhaps) will be stable.
>(Lea)There is another solution, that is perfectly type-safe, but that most
>programmers would find unacceptable: If an operation cannot be
>performed, have the object wait (perhaps forever!), blocking the
>current thread until it CAN be performed. This policy is often
>adopted for example in put/take operations in buffers and queues. But
>it seems the wrong solution for most Collections, don't you think? (In
>fact, buffers, queues, and other channel-like objects should all fall
>under a different interface than java.util.Collection)
(Bergin) I don't like this solution any more than you do. Java is
somewhat hampered, of course, as it adopted a low level construct
(monitors) rather than a higher level concurrency control mechanism.
>(Lea) More generally, I think that this phenomenon of transient service
>availability present in concurrent OO languages leads to substantial
>differences in the design and implementation of many classes.
(Bergin) It may well be that such specialized problems should be
implemented as special cases and should not be allowed to pollute the
development of more generalized and more common solutions.
>
> (Bergin) However, the exception strategy destroys the utility of
interfaces. No variable
> or parameter can be safely typed as one of these interfaces unless you are
> willing to execute only non-optional methods or trap _RUNTIME_ exceptions.
>(Lea) My take on this is that such examples mainly demonstrate the
>inadequacy of interfaces to reveal the kinds of state-dependent action
>policies and protocols rampant in concurrent and distributed programs.
>In practice, this means that users of a given class/object sometimes
>need contractual information about properties and policies that cannot
>be found in interfaces, and is in fact very difficult to express
>except as informal program documentation. (I once wrote a paper on
>this. If you are by chance interested, check out `PSL: Protocols and
>Pragmatics for Open Systems' from my (Doug Lea) home page
>http://gee.cs.oswego.edu/.
http://gee.cs.oswego.edu/dl/oosdw3/index.html
It doesn't present any practical solutions
>though. Chapter 4 of my Concurrent Programming in Java book contains
>some more down-to-earth discussions of policy options.)
(Bergin) I think I agree with you here. Then why is the 1.2 java
proposal using interfaces to try to solve precisely this problem,
requiring abstraction boundary problems for all software developed with
the container classes?
>(Lea) Probably you think I am taking concurrency and distribution issues too
>seriously here. After all, most Java programs are mostly sequential.
>and most collection implementations do not introduce transient method
>availability issues beyond those intrinsic to simple method-level
>locking. But again, it seems like a mistake to limit collections
>to such contexts.