Click here to Skip to main content
12,943,904 members (59,762 online)
Click here to Skip to main content
Add your own
alternative version


26 bookmarked
Posted 9 Feb 2013

Automatic thread synchronization - Exception based class library

, 18 Mar 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
Automatic thread synchronization classes which throw exceptions instead of error codes.


Exceptions are always preferred to return codes in the object oriented world. As we all know it will make the normal flow a fall through and separates the alternate flows (exceptional). It not only makes the normal execution flows efficient (as there is no need to check for returns) but also makes the code more clean and easy to understand. You may be thinking why I am chatty about the very well known facts. Well, I am coming to the point. How about making the automatic thread synchronization classes throw exceptions when the thread wait fails or times out? This is the topic for our discussion.  


This is how we normally deal with thread synchronization, see the code below:

HANDLE hMutex = ::CreateMutex(…);
// other code

DWORD dwReturn = WaitForSingleObject(hMutex,dwTimeOut);
    case WAIT_OBJECT_0:
    // handle success case

    case WAIT_FAILED:
    // handle wait failed.

    case WAIT_TIMEOUT:
    // handle timeout

    // handle wait abandoned


This is OK in the C world. But it looks bad in C++ code. We have MFC synchronization classes such as CMutex, CEvent, CSemaphore etc., that wrap the APIs. Also the associated classes such as CSinlgeLock and CMultiLock make the locks acquire and release automatically. But the Lock function returns either TRUE or FALSE when the wait succeeds or fails. In the case of failure the exact return code is not available. 

See the code snippet below which uses CSingleLock

CSingleLock MyLock(&m_myMutex);

if (MyLock.Lock(500))   
    // Lock success


Now, I think we are in the context and I am proposing a solution to get rid of error codes and use exceptions instead. The synchronization classes which I offer throw exceptions when a wait failed case happens.

This will make the code cleaner as we can deal each of error cases such as WAIT_FAILED, WAIT_TIMEOUT etc., in separate exception handling blocks. The following table shows the error codes and their corresponding exceptions:

Error code



Normal case









The following is the army of classes I have coded to achieve thread synchronization using an exception based strategy:

  • SynchronizerBase
  • CriticalSectionSynchronizer
  • EventSynchronizer 
  • MutexSynchronizer 
  • SemaphoreSynchronizer
  • SingleObjectLock
  • MultiObjectLock

The Synchronizer group of classes provides facilities for thread synchronization using CriticalSection, Event, Mutex, and Semaphore. These classes can be used with automatic locking and lock releasing objects such as SingleObjectLock and MultiObjectLock. SynchronizerBase is the base class for this group of classes. These classes throw exceptions when conditions such as wait timeout arise. As we all know, an exception based mechanism avoids error code checking in the success case. It separates the normal flow and exceptional flow.  

  • CriticalSectionSynchronizer - This class wraps the critical section. It serves as a facilitator for the automatic lock handling class, the SingleObjectLock. SingleObjectLock's constructor calls Lock and destructor calls UnLock.
  • MutexSynchronizer - This class wraps the mutex kernel object. It throws SyncObjectCreationFailed, SyncObjectWaitFailed, SyncObjectWaitTimedOut, SyncObjectWaitAbandoned  exceptions depending on the mutex creation or return of the WaitForSingleObject function.  It acts a facilitator for the automatic lock acquire and release by the SingleObjectLock and   MultiObjectLock classes.
  • SemaphoreSynchronizer - This class wraps the semaphore kernel object. It throws the SyncObjectCreationFailed, SyncObjectWaitFailed, SyncObjectWaitTimedOut exceptions depending on the semaphore creation or return of the WaitForSingleObject function. It acts as a facilitator for automatic lock acquire and release by the SingleObjectLock and MultiObjectLock classes.
  • SingleObjectLock - This class handles automatic lock acquire and release by using a constructor and destructor. It ensures that the lock is properly released with the help of an UnLock call in the destructor. It works with the single object wait function, WaitForSingleObject.
  • MultiObjectLock - This class handles the automatic lock acquire and release by using a constructor and destructor. It works with multiple object wait functions such as the WaitForMultipleObjects and MsgWaitForMultipleObjects. It throws SyncObjectWaitTimedOut,  SyncObjectWaitFailed, SyncObjectWaitAbandoned depending on the return value of the wait function. This object can be used to wait in a worker thread as well as a UI thread. In case a UI thread is specified, it will use MsgWaitForMultipleObjects internally.  The LockHolder keeps the synchronization objects. The sync objects should be added to the LockHolder and passed to the MultiObjectLock instance. The LockHolder can be reused with the local instances of MultiObjectLock.
  • LockHolder - Holds the list of synchronization objects. It is used with MultiObjectLock. The synchronizer list is separated because we can create local instances of MultiObjectLock while the LockHolder object can be reused. So no need to add the synchronizer objects again while creating another instance of MultiObjectLock.

Using the code 

Now, how to use these classes. For an example, see the code below. It shows how you can use the SingleObjectLock. The SingleObjectLock uses WaitForSingleObject whereas MultiObjectLock uses WaitForMultipleObjects and MsgWaitForMultipleObjects (if UI flag is ON). 

// It simulates the mutex wait timedout condition with the help

// of a child thread.

void CThreadSyncClassesDemoDlg::OnBnClickedButtonMutexTimeout()
        THREAD_INFO* pstThreadInfo = new THREAD_INFO;
        pstThreadInfo->eObjType = MUTEX;
        pstThreadInfo->csObjName = GetUniqueKernelObjName();

        // Let thread acquire the mutex

        CWinThread* pTimeoutThread = AfxBeginThread(ExceptionSimulatorThread,pstThreadInfo,0,0);
        AfxMessageBox(_T("Thread acquired OK to timeout"));
        // Try to acquire the mutex and get timeout

        MutexSynchronizer MtxSync(0,FALSE,pstThreadInfo->csObjName);
        SingleObjectLock Lock(&MtxSync,100);
    catch (SyncObjectWaitTimeOut& WaitTimeOut)
        // Your wait timeout handler

    catch(SyncObjectWaitFailed& WaitFailed)
        // Your wait failed handler

    catch(SyncObjectWaitAbandoned& WaitAbandoned)
        // Your wait abandoned handler

    catch(GeneralException& GenException)
        // General handler


The MultiObjectLock needs a helper class LockHolder which manages a container of synchronization objects. As the purpose of MultiObjectLock is to operate as a stack variable, the LockHolder object can be reused. This is particularly handy in the case of waiting in a UI thread where we have to loop around while pumping the messages. The call to MsgWaitForMultipleObjects is wrapped inside a MultiObjectLock constructor. It releases the objects that are signaled in the destructor. The HasMessageInQueue() function can be used to see if MsgWaitForMultipleObjects returned due to a message in the queue. If it returns false that means an object is signaled and we can quit the loop.   

Here is how you can use MultiObjectLock:

// This will simulate the WaitForMultipleObjects timeout condition

void CThreadSyncClassesDemoDlg::OnBnClickedButtonMultiTimeout()
        CString csMutexName = GetUniqueKernelObjName();
        THREAD_INFO* pstThreadInfo = new THREAD_INFO;
        pstThreadInfo->eObjType = MUTEX;
        pstThreadInfo->csObjName = csMutexName;

        // Let the worker thread acquire the mutex...

        CWinThread* pTimeoutThread = AfxBeginThread(ExceptionSimulatorThread,pstThreadInfo,0,0);
        AfxMessageBox(_T("Let the other thread acquire the mutex and we time close"));

        // Prepare mutex and semaphore objects

        typedef std::auto_ptr<SynchronizerBase> SyncObjPtr;
        SyncObjPtr pMutexPtr(new MutexSynchronizer(0,FALSE,csMutexName));
        SyncObjPtr pSemPtr(new SemaphoreSynchronizer(0,FALSE,1,1,1,0,_T("TEST_SEMAPHORE")));
        // Add mutex and semaphore

        LockHolder lhLockHolderObj;
        // Now, try for a WaitForMultipleObjects.

        // It will generate WaitTimeout exception.

        MultiObjectLock Lock(&lhLockHolderObj,TRUE,100,FALSE,0); 
    catch (SyncObjectWaitTimeOut& WaitTimeOut)
    catch(SyncObjectWaitFailed& WaitFailed)
    catch(SyncObjectWaitAbandoned& WaitAbandoned)
    catch(GeneralException& GenException)

See below on how to use MultiObjectLock from a UI thread:

// It will simulate the MsgWaitForMultipleObjects

void CThreadSyncClassesDemoDlg::OnBnClickedButtonUiMultiWait()
    EventSynchronizer EventSync(0,FALSE,TRUE,FALSE,0);
    typedef std::auto_ptr<SynchronizerBase> SyncObjPtr;
    SyncObjPtr pEventPtr(new EventSynchronizer(0,FALSE,TRUE,FALSE,0));
    CWinThread* pUIWaitThread = AfxBeginThread(UIWaitDemoThread,pEventPtr.get(),0,0);
    LockHolder lhLockHolderObj;
        // Call MsgWaitForMultipleObjects and allow to pass input events.

        MultiObjectLock Lock(&lhLockHolderObj,FALSE,INFINITE,TRUE,QS_ALLINPUT); 
        // If the reason to return is not a message, it is the case when the event is

        // signalled, then break the loop.

        // Ensure the messages are dispatched.

        if( !Lock.HasMessageInQueue() )
            AfxMessageBox(_T("Wait complete"));


I have prepared a demo application which simulates the error cases. This will help in quickly understanding the intended usage. MultiObjectLock supports up to MAXIMUM_WAIT_OBJECTS. You have to use the technique of creating multiple threads and wait on thread handles if you want to support more than that. I hope these classes are useful and are more aligned with the object oriented way of dealing with thread synchronization. I am eagerly waiting to see how it is being used. Thank you for the patient reading.


  • 10-Feb-2013 - Released as a set of classes.
  • 18-Mar-2013 - Released as a DLL and made some minor fixes. The demo application uses this library.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

India India
Working in an MNC at Bangalore. I can be reached at
My personal page

You may also be interested in...

Comments and Discussions

QuestionWait function results Pin
geoyar11-Mar-13 8:44
mvpgeoyar11-Mar-13 8:44 
AnswerRe: Wait function results Pin
Sudheesh.P.S12-Mar-13 5:12
memberSudheesh.P.S12-Mar-13 5:12 
GeneralRe: Wait function results Pin
geoyar12-Mar-13 7:32
mvpgeoyar12-Mar-13 7:32 
QuestionI have some doubt. Pin
yafan10-Mar-13 6:17
memberyafan10-Mar-13 6:17 
AnswerRe: I have some doubt. Pin
Sudheesh.P.S11-Mar-13 5:30
memberSudheesh.P.S11-Mar-13 5:30 
GeneralRe: I have some doubt. Pin
yafan11-Mar-13 8:51
memberyafan11-Mar-13 8:51 
GeneralRe: I have some doubt. Pin
Sudheesh.P.S12-Mar-13 4:58
memberSudheesh.P.S12-Mar-13 4:58 
QuestionPerformance Considerations Pin
jcurl5-Mar-13 2:33
memberjcurl5-Mar-13 2:33 
AnswerRe: Performance Considerations Pin
Sudheesh.P.S5-Mar-13 5:19
memberSudheesh.P.S5-Mar-13 5:19 
GeneralRe: Performance Considerations Pin
jcurl5-Mar-13 6:07
memberjcurl5-Mar-13 6:07 
GeneralRe: Performance Considerations Pin
Sudheesh.P.S6-Mar-13 4:03
memberSudheesh.P.S6-Mar-13 4:03 
QuestionOpening sentence - I'd question the wisdom of using exceptions to replace return codes. Pin
Mike Diack5-Mar-13 1:27
memberMike Diack5-Mar-13 1:27 
AnswerRe: Opening sentence - I'd question the wisdom of using exceptions to replace return codes. Pin
Sudheesh.P.S5-Mar-13 5:05
memberSudheesh.P.S5-Mar-13 5:05 
GeneralInteresting approach Pin
H.Brydon9-Feb-13 15:57
memberH.Brydon9-Feb-13 15:57 
GeneralRe: Interesting approach Pin
Sudheesh.P.S11-Feb-13 3:02
memberSudheesh.P.S11-Feb-13 3:02 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170518.1 | Last Updated 18 Mar 2013
Article Copyright 2013 by Sudheesh.P.S
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid