Re: java.io.DataInputStream.readLine misbehaviour

[Bryce McKinlay]

On Nov 3, 2003, at 5:33 AM, Dalibor Topic wrote:

> For what it's worth, yes, there is code out there that expects threads 
> to be able to read from readers/writers and not trip over their feet 
> ;) AFAIK, the Java APIs explicitely mention when a method/class is not 
> thread safe, so by default we should assume that APIs are to be thread 
> safe.

> I mean, it's built in the laguage, why would you want to limit 
> yourself to single threads when you're doing something as important as 
> IO?

Because, in general, IO from multiple threads makes no sense. If 
multiple threads are reading/writing the stream, the behavior is 
non-deterministic. Even if you synchronize correctly, the IO operations 
can occur in any order - there is no way to determine what data each 
thread will receive from the stream, or what the contents of the 
written stream will be.

In order to do meaningful IO from multiple threads, synchronization 
needs to be done at the application level.

We should assume that, unless otherwise stated by the spec, object 
instances do not have to be internally synchronized. Having said that, 
its clear that many of the streams classes must be synchronized by 
design (PrintStream for example), so I agree that in general 
synchronization is required for the streams classes. However this is 
not true for the Java APIs in general.  Sun long ago realised their 
mistake in using synchronization too liberally throughout the older 
class libraries, and thats why mentions of synchronization have been 
removed from the spec for many classes - a hint that developers should 
not assume they are synchronized.

Regards

Bryce.