Monday, June 01, 2009

Multithreading: waiting for several work items

by luisabreu via LA.NET [EN] on 6/1/2009 11:55:23 AM

In the last post, we’ve seen how we could use the thread pool for queuing work items that will be executed in one of the existing threads maintained on the default thread pool. As we’ve seen, there’s no way to say “wait for the executing actions” without using one of the synchronization kernel objects we’ve met in previous posts.

In that last post, I’ve queued one work item and used a ManualResetEvent for waiting until the work is completed. A friend of mine asked me what’s the best option for waiting on several work items. Should we use several kernel objects? Here’s the code we generally see in these cases:

var evts = Enumerable.Range(0, 3)
        .Select(i => new ManualResetEvent(false))
        .ToArray();
var wrkThreads = Enumerable.Range(0, 3)
        .Select(i => new Thread(() => { Console.WriteLine("Thread {0}", i); Thread.Sleep(2000); evts.Set(); }));
Console.WriteLine( "Starting secondaryThreads");
foreach(var t in wrkThreads){
   t.Start();
}
WaitHandle.WaitAll(evts);

Yes, this works and you’ll see it across several MSDN samples…no doubt about it. But is this really the best option? It might be, but can we get away without using all those event objects? Yes, we can :) How? let’s think about it…and what if instead of creating several events, we had only one and used a counter for signaling it when everything is done? Here’s how it would look like:

var evt = new ManualResetEvent(false);
var cbCounter = 3;
var wrkThreads = Enumerable.Range(0, cbCounter)
      .Select(i => new Thread(() => {
                                Console.WriteLine("Thread {0}", i);
                                Thread.Sleep(2000);
                                if( Interlocked.Decrement(ref cbCounter) == 0 ){
                                    evt.Set();
                                }
      }));
Console.WriteLine( "Starting secondaryThreads");
foreach(var t in wrkThreads){
  t.Start();
}
evt.WaitOne();

Notice that we’re using the Interlocked.Decrement method for decrementing the counter in an atomic and thread safe way. I’ve also seen this code written by using locks, but I think that the Decrement method invocation is the preferred option for most (if not all) cases.

And that‘s it. Keep tuned for more.