On Apr 28, 2004, at 7:16 AM, Doron Rajwan wrote:
> Tiger beta1 libs has lots of unsynchronized gettes.
> ByteArrayOutputStream, for example, has all update
> methods synchronized, but all the getters, such as
> size(), are not.
It is incorrect synchronization.
The only question is how serious is it?
If an unsynchronized getter that performs only a single read
of a field, and that field contains an integer or a reference
to an immutable object, I wouldn't consider it serious.
While incorrect, there are a lot more serious unfixed bugs.
We do have some checks for stuff like this in FindBugs,
but we wouldn't report the size function as a problem.
On the other hand, in the toString methods of ByteArrayOutputStream,
there are unsynchronized reads of both buf and count. If another
thread is updating the ByteArrayOutputStream, it could see inconsistent
leading to an array index out of bound error.
> 1. Is this a bug, or maybe this class was not suppose
> to be thread-safe in the first place?
It is almost entirely useful to make ByteArrayOutputStream
thread safe, because you always need additional synchronization
to make sure any interleaving of calls is done with the correct
level of transaction granularity. There is nothing in the JavaDoc
that claims ByteArrayOutputStream is thread safe, and we've often
wondered if we could just remove the synchronization from many
of the java.io classes.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:06 EDT