[Libreoffice-commits] core.git: Branch 'private/swe/libreoffice-5-2+backports' - 3 commits - vcl/source

[Stephan Bergmann]

 vcl/source/app/scheduler.cxx |   26 ++++++--------------------
 1 file changed, 6 insertions(+), 20 deletions(-)

New commits:
commit 2767a7effe575af03b71855b3d4b316a97e8be38
Author: Stephan Bergmann <sbergman at redhat.com>
Date:   Wed Aug 9 12:14:28 2017 +0200

    Rephrase SchedulerMutex::acquire so it would work for nLockCount=0
    
    Change-Id: Ibd5f45b5829e51f872e90a4256ae875bc5d363d4

diff --git a/vcl/source/app/scheduler.cxx b/vcl/source/app/scheduler.cxx
index a3e4924b094d..6f3c4a4c8f35 100644
--- a/vcl/source/app/scheduler.cxx
+++ b/vcl/source/app/scheduler.cxx
@@ -121,12 +121,11 @@ void Scheduler::ImplDeInitScheduler()
 
 bool SchedulerMutex::acquire( sal_uInt32 nLockCount )
 {
-    do {
+    for (sal_uInt32 i = 0; i != nLockCount; ++i) {
         if ( !maMutex.acquire() )
             return false;
         ++mnLockDepth;
     }
-    while ( --nLockCount );
     return true;
 }
 
commit 6a5d2dc840a3af73115fcecdc681d6f26dea5e77
Author: Stephan Bergmann <sbergman at redhat.com>
Date:   Wed Aug 9 10:02:35 2017 +0200

    Remove unnecessary, broken check for mnLockDepth != 0
    
    If SchedulerMutex::release were ever called from a thread not having locked the
    mutex, mnLockDepth would have an arbitrary value, not necessarily zero.  It is
    clear that SchedulerMutex::release must only be called by a thread that has the
    mutex locked, so the check was redundant.
    
    Change-Id: I4969b8e6543657602494e333a6a3ea07d83267d1

diff --git a/vcl/source/app/scheduler.cxx b/vcl/source/app/scheduler.cxx
index 419cdf23af1f..a3e4924b094d 100644
--- a/vcl/source/app/scheduler.cxx
+++ b/vcl/source/app/scheduler.cxx
@@ -132,14 +132,11 @@ bool SchedulerMutex::acquire( sal_uInt32 nLockCount )
 
 sal_uInt32 SchedulerMutex::release( bool bUnlockAll )
 {
-    sal_uInt32 nLockCount = 0;
-    if ( mnLockDepth )
-    {
-        nLockCount = bUnlockAll ? mnLockDepth : 1;
-        mnLockDepth -= nLockCount;
-        for (sal_uInt32 i = 0; i != nLockCount; ++i) {
-            maMutex.release();
-        }
+    assert(mnLockDepth != 0);
+    sal_uInt32 nLockCount = bUnlockAll ? mnLockDepth : 1;
+    mnLockDepth -= nLockCount;
+    for (sal_uInt32 i = 0; i != nLockCount; ++i) {
+        maMutex.release();
     }
     return nLockCount;
 }
commit 1c6c1329df23d779c46b9928c3cd188c38686996
Author: Stephan Bergmann <sbergman at redhat.com>
Date:   Wed Aug 9 08:46:13 2017 +0200

    SchedulerMutex::release: don't read mnLockDepth with maMutex already unlocked
    
    ...another thread may already have called SchedulerMutex::acquire in between,
    whose effect would then be canceled
    
    Change-Id: Icddb6ea47144366c3a81bc83e3f9469b25a18c22

diff --git a/vcl/source/app/scheduler.cxx b/vcl/source/app/scheduler.cxx
index ccd127c08453..419cdf23af1f 100644
--- a/vcl/source/app/scheduler.cxx
+++ b/vcl/source/app/scheduler.cxx
@@ -135,19 +135,9 @@ sal_uInt32 SchedulerMutex::release( bool bUnlockAll )
     sal_uInt32 nLockCount = 0;
     if ( mnLockDepth )
     {
-        if ( bUnlockAll )
-        {
-            nLockCount = mnLockDepth;
-            do {
-                --mnLockDepth;
-                maMutex.release();
-            }
-            while ( mnLockDepth );
-        }
-        else
-        {
-            nLockCount = 1;
-            --mnLockDepth;
+        nLockCount = bUnlockAll ? mnLockDepth : 1;
+        mnLockDepth -= nLockCount;
+        for (sal_uInt32 i = 0; i != nLockCount; ++i) {
             maMutex.release();
         }
     }