You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Peter Firmstone (JIRA)" <ji...@apache.org> on 2015/12/04 11:59:10 UTC

[jira] [Updated] (RIVER-431) Java Memory Model Compliance

     [ https://issues.apache.org/jira/browse/RIVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Firmstone updated RIVER-431:
----------------------------------
    Fix Version/s: River_3.0.0

> 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
>             Fix For: River_3.0.0
>
>         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.3.4#6332)