• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 316
  • Last Modified:

When Should I Have an Event for Each Thread? - C++

1. When would be appropriate to use an event for each thread?

2. Mutex should be used when two threads are reading/writing to a shared resource, right? Is there an alternative - just curious to know?

2 Solutions
A summary of thread syncronization objects:

evilrixSenior Software Engineer (Avast)Commented:
1. When you need to signal the thread externally from another thread.

2. Yes a mutex (mutual exclusion) object is used to sync events. You can also use a CriticalSection on Windows, which is lighter weight because unlike a mutex it doesn't generally require transition to kernel mode (a special mode where the kernel is on control).


If you just want to do simple things such as increment or change a value Windows provides a set of simple Interlock functions to do this


On linux you can use a semaphore; however, mutexes are generally just specializations of semaphore to give them mutual exclusion semantics.


It's actually possible to provide mutex semantics without any special objects; however, the code to provide the required interlocking is very complex and beyond the scope of this thread.
>>>> When would be appropriate to use an event for each thread?

I am using events before mutexes if I need a one-time synchronisation between threads. Here an event IMO is more straight-forward. Assume you have local data in the main thread and you want to pass a pointer to the local data  to a worker thread. Then, the main thread has to wait for the worker thread to start and copy the data before it could delete the local data. For that scenario a mutex is not appropriate cause the main thread need to wait for the worker thread which isn't yet active, hence it couldn't set the lock the main thread could wait for.

>>>> Is there an alternative - just curious to know?
you can give each thread its own piece of the shared resource where it is has exclusive right to write on. The other thread() would only read from released data of that part. Think of a message queue which contains 10 released messages. The worker thread can add a new message without problem and increases the message counter when that was done. Any reader would read only up to the current message counter. The problem with such concepts is that they can't easily made safe if you want delete messages from the queue. If there is only one reader, the reader could delete messages after read but may not update any container attribute which was necessary for the writing part of the container. Nevertheless these concepts were very difficult and using a mutex for exclusive access to a container is much easier.

>>>>It's actually possible to provide mutex semantics without any special objects;

In Windows you could use the InterlockedIncrement which provides an atomar incrementing of a shared (global) integer variable.  Atomar means that while the integer was incremented there is no interrupt so that two threads both could increment nearly same time but only one increment actually was done.

The global integer was initialized with zero waht means no lock. The mutex lock for an exclusive code part then looks like

  while (InterlockedIncrement(&global_lock) > 1)
        // if coming here a second thread has done the same
        // we make our own increment reverse and try again
        Sleep(10);   // wait 10 milliseconds
  // Coming here we are exclusive cause the global integer is 1

  // do something exclusive

  // release lock after use
F-J-KAuthor Commented:
Well done. I'm pretty new to multi-threading. It does not seem an easy thing to learn, it can get so complex as far as i see.

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now