[concurrency-interest] Contract of java.io.OutputStream.write(byte b)
Dhanji R. Prasanna
dhanji at gmail.com
Wed May 31 23:23:49 EDT 2006
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.
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest