[
https://issues.apache.org/jira/browse/RIVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Firmstone updated RIVER-431:
----------------------------------
Attachment: RegistrarImpl.patch
Example of changes for Reggie's JMM compliance.
Exporting and starting of threads delayed until after construction.
Initializer object used during construction to allow numerous fields to be made
final.
Internal classes made static with final fields where possible.
Using ReadersWriter to protect all mutable state from public methods.
Other state made volatile when required to be visible to other threads,
comments indicate this.
> Java Memory Model Compliance
> ----------------------------
>
> Key: RIVER-431
> URL: https://issues.apache.org/jira/browse/RIVER-431
> Project: River
> Issue Type: Bug
> Environment: JVM
> Reporter: Peter Firmstone
> Assignee: Peter Firmstone
> Attachments: RegistrarImpl.patch
>
>
> Much of the Jini codebase was written prior to the publication of the current
> JMM, for this reason, there are a number of issues with the existing code
> base that need to be changed to bring River into compliance with the JMM.
> Typical issues encountered:
> 1.Letting "this" escape during construction - example exporting or starting
> threads, where those threads can see internal field references before
> construction of that object is complete.
> 2. Inadequate synchronization or lack of synchronization on mutable fields.
> 3. Sharing of internal unsynchronized state.
> 4. Race conditions where unsynchronized or non final or non volatile fields
> are updated by other threads.
> 5. Deserializing an object in one thread and sharing the deserialized mutable
> but unmodified object with another thread without first publishing it safely
> to a volatile or final field, so the second thread can sometimes see the
> default value of fields in the mutable object.
> Affects all presently released versions, planned to be fixed in River 3.0
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
