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@redhat.com>

0 files changed, 0 insertions, 0 deletions