[
https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308877#comment-17308877
]
Kirk Lund commented on GEODE-9033:
----------------------------------
Non-volatile fields may flush at any unspecified time, so yes it may read the
value later.
I remember Java Concurrency in Practice making the claim that reading/writing a
volatile field or acquiring synchronization on any monitor will cause all
non-volatile fields to flush as well. I suspect it's chapter 16 that explains
this.
So, if the code writes to a non-volatile field and then writes to a volatile
field, all other thread(s) that read the volatile field should also immediately
have visibility to all other non-volatile fields that changed.
Atomics might be another option. Since they handle non-blocking spinning, one
of the API methods might provide what's needed without having to write
something custom. Chapter 14 talks about how to write custom synchronization
which is what it sounds like you're leaning towards. Chapter 15 has some good
info about Atomics as well.
> client read operations should not be blocked by a write operation
> -----------------------------------------------------------------
>
> Key: GEODE-9033
> URL: https://issues.apache.org/jira/browse/GEODE-9033
> Project: Geode
> Issue Type: Improvement
> Components: client/server
> Affects Versions: 1.1.0
> Reporter: Darrel Schneider
> Priority: Major
>
> Client read operations currently will be blocked by a write operation that is
> in progress.
> This is caused by the write operation holding a synchronization on the
> RegionEntry and LocalRegion.getDeserializedValue synchronizing the
> RegionEntry with clientEvent is not null in order to atomically obtain both
> the entry's value and version.
> The read code in LocalRegion that causes this is:
> {code:java}
> synchronized (regionEntry) {
> // value & version must be obtained atomically
>
> clientEvent.setVersionTag(regionEntry.getVersionStamp().asVersionTag());
> value = getDeserialized(regionEntry, updateStats,
> disableCopyOnRead,
> preferCachedDeserializable, retainResult);
> }
> {code}
> To fix this it may be possible to change the write operations to synchronize
> on something else while changing both the value and version (but not while
> doing anything else). Then the read code can sync on that new Object and not
> the RegionEntry instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
