I was reading AutoResetEvent documentation on MSDN and following warning kinda bothers me..
“Important:
There is no guarantee that every call to the Set method will release a thread. If two calls are too close together, so that the second call occurs before a thread has been released, only one thread is released. It is as if the second call did not happen. Also, if Set is called when there are no threads waiting and the AutoResetEvent is already signaled, the call has no effect.”
But this warning basically kills the very reason to have such a thread synchronization techniques. For example I have a list which will hold jobs. And there is only one producer which will add jobs to the list. I have consumers (more than one), waiting to get the job from the list.. something like this..
Producer:
void AddJob(Job j)
{
lock(qLock)
{
jobQ.Enqueue(j);
}
newJobEvent.Set(); // newJobEvent is AutoResetEvent
}
Consumer
void Run()
{
while(canRun)
{
newJobEvent.WaitOne();
IJob job = null;
lock(qLock)
{
job = jobQ.Dequeue();
}
// process job
}
}
If the above warning is true, then if I enqueue two jobs very quickly, only one thread will pick up the job, isn’t it? I was under the assumption that Set will be atomic, that is it does the following:
- Set the event
- If threads are waiting, pick one thread to wake up
- reset the event
- run the selected thread.
So I am basically confused about the warning in MSDN. is it a valid warning?
Even if the warning isn’t true and Set is atomic, why would you use an AutoResetEvent here? Let’s say you have some producers queue up 3 events in row and there’s one consumer. After processing the 2nd job, the consumer blocks and never processes the third.
I would use a ReaderWriterLockSlim for this type of synchronization. Basically, you need multiple producers to be able to have write locks, but you don’t want consumers to lock out producers for a long time while they are only reading the queue size.