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

Joe Bowbeer joe.bowbeer at gmail.com
Thu Jun 1 00:57:07 EDT 2006


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:

  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.


If clean code is the goal, my preference is to avoid explicit locking
in favor or queueing.

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


On 5/31/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
> On 6/1/06, Bill Pugh <pugh at cs.umd.edu> wrote:
> > The fact that many of the implementations of OutputStream are
> > synchronized was
> > a pretty horrible design mistake.
> >
> > If you have two different threads trying to push bytes into an output
> > stream, I'm hard pressed to
> > imagine situations in which allowing the threads to non-
> > deterministically interleave is a good idea.
> >
> > If you are creating your own implementation of OutputStream, I would
> > recommending avoiding any
> > use of synchronization. It serves no purpose, reduces performance,
> > and I don't believe the class
> > contract (or Sun's TCK tests) require it.
>
> that sounds quite sensible.
> 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).
> In any case isnt it better practise to synchronize on a buffer and
> allow only one thread access to the underlying outputstream?
>
> >
> >         Bill Pugh
> >
> >
> > On May 31, 2006, at 6:33 PM, Elias Ross wrote:
> >
> > >
> > > I know this isn't really the forum for asking this, but I've spent a
> > > number of hours looking into a definite yes or no...
> > >
> > > I wanted to know if OutputStream.write(byte b[]) was considered
> > > atomic.
> > > If two threads are writing to the same file, would the output from
> > > OS.write(...) overlap with another OS.write(...)?
> > >
> > > I eventually downloaded the Java source to answer this question.  The
> > > JavaDoc did not specify.  As it turns out, the answer is "no" -- which
> > > is something that you'd only be able to determine by looking at the C
> > > source code for the native calls.
> > >
> > > The JDK interpretation of write() is slightly different than the UNIX
> > > one, which looks like this:
> > >
> > >        ssize_t write(int fd, const void *buf, size_t count);
> > >
> > > so it makes sense that a Java write() call may have to do more than
> > > one
> > > system write() call.
> > >
> > > I wonder if there some better way that "concurrent" and "atomic"
> > > methods
> > > can be documented in the JDK?  It's also very helpful as a user to
> > > know
> > > if I should be locking on the OutputStream itself or create my own
> > > locks.
> > >
> >
>


More information about the Concurrency-interest mailing list