[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: java.io.DataInputStream.readLine misbehaviour
From: |
Bryce McKinlay |
Subject: |
Re: java.io.DataInputStream.readLine misbehaviour |
Date: |
Sat, 8 Nov 2003 09:12:34 +1300 |
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.