[concurrency-interest] Contract of java.io.OutputStream.write(byte b[])

Joe Bowbeer joe.bowbeer at gmail.com
Thu Jun 1 02:44:30 EDT 2006


On 5/31/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:

> are you suggesting deprecation of wait() and notify() altogether?

I wouldn't say "deprecate".  What I would say is that I advise against
their use :-)

There's very little need for anyone to write code that calls these
low-level methods, and when they do there are almost always bugs.
(Show me a wait and a notify and I'll show you a bug -- it almost
never fails!)

I would prefer that a higher level construct were used, such as a
Queue or Future or even an explicit Condition:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Condition.html


On 5/31/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
> On 6/1/06, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> > At the risk of drifting away from the original question, in which
> > locking of the output stream was the stated goal... see comments
> > below.
> >
> > On 5/31/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
> >
> > > I would also suggest using wait() and notify() for deterministic
> > > synchronization at the producer level (user of the outputstream)
> > > as opposed to a synchronized block unless the latter is more
> > > appropriate (optimistic stream writes).
> >
> > Can you explain further?
> >
> > While I don't advocate upgrading every "synchronized" to some form of
> > java.util.concurrent.locks.Lock:
> >
>
> wait(), notify() offers a simple way of ordering behavior in a
> producer-consumer couple. That's all I meant. synchronized() will
> yield non-deterministic behavior with regard to the order of the
> queue/buffer as has been noted elsewhere in this thread.
>
> >   New lock classes improve on synchronized -- but don't replace it
> >   http://www-128.ibm.com/developerworks/java/library/j-jtp10264/
> >
> > I *do* advocate stamping-out all explicit obj.wait()s and
> > obj.notify()s.  Given all the tools in java.util.concurrent, there's
> > got to be something better already implemented.
> >
>
> Correct me if I'm wrong but to my understanding
> java.util.concurrent.locks is an extended, more flexible toolkit for
> concurrency (for situations such as releasing locks in non-lexical
> strictness) and not a replacement for the language basics, whether
> synchronized or wait/notify.
> The 1.5 javadoc for java.util.concurrent.locks.Lock says something to
> this effect.
>
> Or am I totally on the wrong trail to oregon (the one that goes via
> mexico ;)--are you suggesting deprecation of wait() and notify()
> altogether?
>
> >
> > If clean code is the goal, my preference is to avoid explicit locking
> > in favor or queueing.
> >
>
> I completely agree with this. Explicit locking should be hidden by the
> api with threadsafe/concurrent queues. At the risk of drifting
> (along), my point above is for academic or other areas where
> threadsafe queues may not be feasible (like soft realtime apps).
>
> > In other words, producers insert their byte[]s onto a thread-safe
> > queue, while an outputter thread pulls byte[]s from the queue and
> > writes them to the stream.  This separation of concerns results in
> > very clean code. Furthermore, several flavors of queue have already
> > been implemented in java.util.concurrent.
> >
> > --Joe
> >


More information about the Concurrency-interest mailing list