[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: misbehaviour

From: Bryce McKinlay
Subject: Re: 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]