Question

Here is my attempt at implementing a C++ event.

class Event{
    typedef std::tr1::function<void( int& )> CallbackFunction;
    std::list< CallbackFunction > m_handlers;

    template<class M>
    void AddHandler(M& thisPtr, void typename (M::*callback)(int&)) 
    {           
        CallbackFunction bound = std::tr1::bind(callback, &thisPtr, _1);
        m_handlers.push_back(bound);
    }

    void operator()(int& eventArg) 
    { 
        iterate over list...
        (*iter)(eventArg);

    }}

The trouble here is thread-safety. If AddHandler and operator() are called at the same time things could break.

What is the best way to sync this? Using a mutex could kill performance. I wonder what happens behind the scenes of boost::signals or C# event in this case.

Answer 1

A mutex is definitely what you’re looking for. If each Event has its own mutex, I wouldn’t worry much about performance; the reason is that unless you’re adding a lot of handlers during the time you’re handling events, it’s unlikely the mutex will be in contention and slow you down.

However, if you have more than one thread calling the operator() method on the same object, this mutex could be a problem. But without it, how will you ensure your callbacks are invoked in a thread-safe way anyhow? (I notice you’re passing in an integer reference and returning void, so I’m assuming these are not reentrant handlers.)

EDIT: very good question in your comment. To be honest, I never put much thought into whether or not mutexes had much overhead when used in a synchronous way. So I put together this little test.

#include <stdio.h>
#include <pthread.h>

#define USE_PTHREAD_MUTEX 1

int main(int argc, char * argv[]) {

pthread_mutex_t mutex;
pthread_mutex_init(&mutex, NULL);

long useless_number = 0;
long counter;

  for(counter = 0; counter < 100000000; counter++) {
    #if USE_PTHREAD_MUTEX
    pthread_mutex_lock(&mutex);
    #endif
    useless_number += rand();

    #if USE_PTHREAD_MUTEX
    pthread_mutex_unlock(&mutex);
    #endif
  }

  printf("%ld\n", useless_number);

}

I ran this on my system and got the following runtimes.

With USE_PTHREAD_MUTEX 0, the average runtime is 1.2 seconds.

With USE_PTHREAD_MUTEX 1, the average runtime is 2.8 seconds.

Thus, to answer your question, there is definitely overhead. Your mileage may vary. Besides, if multiple threads are competing for access to a resource, more time will be spent blocking, necessarily. Also, in a purely synchronous context, it’s likely that more time will be spent accessing the shared resource than waiting for a mutex to lock/unlock. That is to say, the overhead of the mutex logic itself will probably be insignificant compared to these things.