[
https://issues.apache.org/jira/browse/FELIX-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668800#action_12668800
]
Stuart McCulloch commented on FELIX-908:
----------------------------------------
A plain int field is still different from a volatile int, because in the Java
Memory Model different threads could see different values in the same int field
because of caching, etc. (of course in reality this might never happen, it
depends on the actual architecture of the OS, etc.) Marking a field as volatile
implies a memory fence, and also stops the JIT from re-ordering statements,
which could also break assumptions about the field. So there is a difference,
but it's not always obvious.
Pre-Java 5 this was all a bit of a mess, and many JVMs didn't support volatile
longs properly - with Java 5 things are much better, and the semantics are
cleaner.
See http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html
for a nice overview and http://gee.cs.oswego.edu/dl/jmm/cookbook.html for the
gory details :)
Getting back to the issue, using volatile doesn't imply a dependency on Java 5
- unless you're relying on specific assumptions (like the double-checked
locking idiom). We already use volatile in other places in Felix that have high
contention, the question here is whether using volatile will break the bundle
state machine - will need to look more closely at this code to be sure. ie. if
only one thread is writing to the state and all other threads read it then
volatile is fine, the problem is if two or more threads need to both read and
write to it concurrently.
> Unsynchronize access to bundle state inside BundleInfo by making the variable
> volatile
> --------------------------------------------------------------------------------------
>
> Key: FELIX-908
> URL: https://issues.apache.org/jira/browse/FELIX-908
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: felix-1.2.1
> Reporter: Anatoli Kazatchkov
> Priority: Minor
> Attachments: bundle_info.patch
>
>
> Synchronized access to bundle state inside {{BundleInfo}} class creates an
> unnecessary contention point in environments where {{bundle.getState()}} is
> called a lot.
> Declaring {{m_state}} variable volatile and removing synchronization from
> {{setState()}} and {{getState()}} will do the trick.I will attach the patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
