[concurrency-interest] Contract of java.io.OutputStream.write(byte b)
pugh at cs.umd.edu
Wed May 31 20:53:05 EDT 2006
The fact that many of the implementations of OutputStream are
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.
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
> 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
> system write() call.
> I wonder if there some better way that "concurrent" and "atomic"
> can be documented in the JDK? It's also very helpful as a user to
> if I should be locking on the OutputStream itself or create my own
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest