[Libreoffice-commits] core.git: chart2/source

[Stephan Bergmann (via logerrit)]

 chart2/source/inc/LifeTime.hxx |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit f3251c3185c68f07975aacb3502dfaf7b2dabccd
Author:     Stephan Bergmann <sbergman at redhat.com>
AuthorDate: Mon Sep 16 17:00:16 2019 +0200
Commit:     Stephan Bergmann <sbergman at redhat.com>
CommitDate: Mon Sep 16 21:00:58 2019 +0200

    Remove confused "volatile" from LifeTimeManager sal_Int32 members
    
    Lets assume that "volatile" was (confusedly) meant to address multi-threading
    races (rather than signal handler races), but all access to the
    LifeTimeManager::m_nAccessCount and LifeTimeManager::m_nLongLastingCallCount
    members is apparently covered by LifeTimeManager::m_aAccessMutex anyway:  They
    are accessed in
    
    * LifeTimeManager::impl_registerApiCall
    * LifeTimeManager::impl_unregisterApiCall
    * CloseableLifeTimeManager::g_close_isNeedToCancelLongLastingCalls
    
    where in the latter access is covered by a corresponding
    LifeTimeManager::m_aAccessMutex guard.  And calls to the former are made from
    
    * CloseableLifeTimeManager::g_close_endTryClose
    * CloseableLifeTimeManager::g_close_startTryClose
    * CloseableLifeTimeManager::g_close_endTryClose_doClose
    * LifeTimeGuard::~LifeTimeGuard
    * LifeTimeGuard::startApiCall
    
    where all but the last have the calls covered by a corresponding
    LifeTimeManager::m_aAccessMutex guard.  And all calls to
    LifeTimeGuard::startApiCall are made from
    
    * chart2/source/model/main/ChartModel.cxx
    * chart2/source/model/main/ChartModel_Persistence.cxx
    
    following a pattern of
    
        LifeTimeGuard aGuard(m_aLifeTimeManager);
        if(!aGuard.startApiCall()) ...
    
    where the LifeTimeGuard ctor will lock the corresponding
    LifeTimeManager::m_aAccessMutex.
    
    (There are further volatile members in LifeTimeManager and
    CloseableLifeTimeManager of type bool, which are probably equally confused.  But
    lets leave those for another clean-up.  These sal_Int32 volatile members started
    to cause -Werror=volatile (like "error: '++' expression of 'volatile'-qualified
    type is deprecated") with recent GCC 10 trunk in C++20 mode.)
    
    Change-Id: I3d15caba151d697344ce30e90298abd6028d40d5
    Reviewed-on: https://gerrit.libreoffice.org/79022
    Tested-by: Jenkins
    Reviewed-by: Stephan Bergmann <sbergman at redhat.com>

diff --git a/chart2/source/inc/LifeTime.hxx b/chart2/source/inc/LifeTime.hxx
index 4406b5cd70b9..73d2b70cbbab 100644
--- a/chart2/source/inc/LifeTime.hxx
+++ b/chart2/source/inc/LifeTime.hxx
@@ -59,13 +59,13 @@ protected:
     css::lang::XComponent*     m_pComponent;
 
     ::osl::Condition        m_aNoAccessCountCondition;
-    sal_Int32 volatile      m_nAccessCount;
+    sal_Int32               m_nAccessCount;
 
     bool volatile       m_bDisposed;
     bool volatile       m_bInDispose;
 
     ::osl::Condition        m_aNoLongLastingCallCountCondition;
-    sal_Int32 volatile      m_nLongLastingCallCount;
+    sal_Int32               m_nLongLastingCallCount;
 };
 
 class CloseableLifeTimeManager final : public LifeTimeManager