You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Tim Ellison (JIRA)" <ji...@apache.org> on 2006/06/13 12:36:30 UTC
[jira] Assigned: (HARMONY-597) Synchronization on non-final field
in DataInputStream/DataOutputStream
[ http://issues.apache.org/jira/browse/HARMONY-597?page=all ]
Tim Ellison reassigned HARMONY-597:
-----------------------------------
Assign To: Tim Ellison
> Synchronization on non-final field in DataInputStream/DataOutputStream
> ----------------------------------------------------------------------
>
> Key: HARMONY-597
> URL: http://issues.apache.org/jira/browse/HARMONY-597
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Dain Sundstrom
> Assignee: Tim Ellison
> Priority: Critical
>
> It appears that the DataInputStream and DataOutputStream classes use a shared buffer to reduce the creation of temporary buffer space. This buffer is contained in the static DataInputStream.byteBuf field and access to this field is controled by the boolean flag DataInputStream.useShared. Access to this field is gated by a synchronized lock on the byteBuf field. The problem is that sometimes code set the useShared field to false and then resizes the buffer by creating a new one. Since the lock object itself is changing the lock is virtually useless. This problem can be eliminated by synchronizing on a static final object instead of the buffer itself.
> I think this code should be reexamined in it's entirety to determine if performance improvement of a shared buffer is worth the added complexity. If such a determination is made, I suggest the code is rewritten using Java5 concurrency primitives.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira