[
https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated CODEC-55:
---------------------------
The original reason this bug was opened
"QCodec is definitely not thread-safe; the method setEncodeBlanks() updates
an instance variable."
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: https://issues.apache.org/jira/browse/CODEC-55
> 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.
