[jira] [Commented] (GEODE-5314) MBeanStatsMonitor child classes should use atomics instead of volatiles to avoid data race

["Galen O'Sullivan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16619849#comment-16619849 ] 

Galen O'Sullivan commented on GEODE-5314:
-----------------------------------------

Per discussion in the PR, it looks like there is a single Statistics thread, which means that this is not creating a data race as I had thought.

> MBeanStatsMonitor child classes should use atomics instead of volatiles to avoid data race
> ------------------------------------------------------------------------------------------
>
>                 Key: GEODE-5314
>                 URL: https://issues.apache.org/jira/browse/GEODE-5314
>             Project: Geode
>          Issue Type: Bug
>          Components: statistics
>            Reporter: Galen O'Sullivan
>            Assignee: Juan José Ramos Cassella
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> {{GcStatsMonitor}} has the following:
> {code}
>   private volatile long collections = 0;
>   private volatile long collectionTime = 0;
> {code}
> <snip>
> {code}
>     collections -= statsMap.getOrDefault(StatsKey.VM_GC_STATS_COLLECTIONS,0).intValue();
>     collectionTime -= statsMap.getOrDefault(StatsKey.VM_GC_STATS_COLLECTION_TIME,0).intValue();
> {code}
> Because these are volatile and not atomic fields, there will be a race condition. Other subclasses of {{MBeanStatsMonitor}} also use volatiles: AggregateRegionStatsMonitor, GatewaySenderOverflowMonitor, MemberLevelDiskMonitor, VMStatsMonitor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)