[
https://issues.apache.org/jira/browse/UIMA-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471291
]
Marshall Schor commented on UIMA-284:
-------------------------------------
A (partial) list of things being investigated and corrected:
In several place, a field was "read" without synch, which was settable in
another thread, and used to control if a "wait" was done. This can have the
effect: the other thread sets this to a value to cause a wait, but the wait
doesn't happen because the read reads a different value - due to the Java
memory model.
In other places, a wait was done conditionally. The field that was read to see
if the wait should be done was done outside of the synch block containing the
wait. If the condition changed on another thread and the notify or notify-all
given for this change, between the time the read was done, and the wait
occurred, the wait would not see the notify or notify-all, and would wait
indefinately. The test to see if the wait should be done and the wait itself
need to be contained within on synch block that synch's on the same object that
the code in the other thread(s) would use when doing variable modifications and
notifies.
In several places, a field was being used to hold an object that was used in
wait, notify, synch. But the object being used was the object associated with
"" (a 0 length string). JVMs are allowed to (but not required to) merge
different instances of "" into just one object, because they're immutable.
This causes waits/notifies/synch's associated with these objects to sometimes
be shared, other times not.
There is a case in jVinci where the code does an assignment to a field of a new
instance, followed by a synch on that new instance. This is unlikely to be the
designed-for behavior - since every call of that code would be synch-ing on a
different object.
> Synchronization issues
> ----------------------
>
> Key: UIMA-284
> URL: https://issues.apache.org/jira/browse/UIMA-284
> Project: UIMA
> Issue Type: Bug
> Components: Collection Processing, Core Java Framework
> Reporter: Marshall Schor
> Assigned To: Marshall Schor
>
> Based on some feedback from a user reporting difficulties running large-scale
> CPM / Vinci deployments, a code inspection has uncovered some potential
> issues in jVinci, the Core, and Collection Processing code around
> multi-threading, synchronization, waiting/notifying, and accomodating the
> Java Memory Model.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
