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

[Bill Pugh]

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.

	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