[RIVER-431] Java Memory Model Compliance

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: River_2.1.1, River_2.1.2, River_2.2.0, River_2.2.1, River_2.2.2
• Fix Version/s: River_3.0.0

Environment

JVM

• Workaround: None, River is highly multi threaded, remote calls invoked on exported objects are executed by the ThreadPool Executor, so all exported objects must be thread safe.
• Assignee: Peter Firmstone
• Reporter: Peter Firmstone
• Due: 01/Mar/14
• Created: 17/Dec/13 00:33
• Updated: 21/Dec/15 10:21
• Resolved: 04/Dec/15 10:59

Description

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

Issue Links

• incorporates: RIVER-420 Export during construction.