commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Pugh (JIRA)" <>
Subject [jira] Updated: (CODEC-55) make all "business" method implementations of public API thread safe
Date Wed, 10 Oct 2007 16:56:51 GMT


Will Pugh updated CODEC-55:

The original reason this bug was opened 

    "QCodec is definitely not thread-safe; the method setEncodeBlanks() updates an instance

Wanting to set EncodingBlanks or really any such setter is in general a really bad idea when
working with thread, because it is changing the way an object works under the other thread.
 Adding synchronization does not help.  There are so many gotchas in threading, that you cannot
put them all in documentation.  Some of it you need to assume your user knows.

Turns out, this is a bad assumption.  Threading is still a fairly complex bit.  It occurred
to me that building an object that would protect against user error is not a bad idea.  The
problem is, the currently attached diff does not actually do this.

The current problem is that the end of a constructor in no way guarantees that all threads
will see the same values in each field of an object.  In the Java 1.5 MM specification, final
fields will be guaranteed to be consistent across threads and if the fields were volatile
there is a happens-before edge between the write and the read.

The way it currently is written, this is no so.  Non-final fields either need to be made volatile,
or the solution would be to move to static functions, and assume people know enough about
what they are doing to not shoot themselves (although, in actuality the read/write order issues
are extremely rare in the wild, improperly written code could live out it's life and not see
an issue).

> make all "business" method implementations of public API thread safe 
> ---------------------------------------------------------------------
>                 Key: CODEC-55
>                 URL:
>             Project: Commons Codec
>          Issue Type: Wish
>            Reporter: Qingtian Wang
>         Attachments: concurrentCodecs.diff, concurrentQDiff.diff, urlcodec.patch
> Maybe most of the implementations are already thread safe. Just such that codec can say
so in general...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message