Is it OK to use Pulse & Wait? Or it is evil and a cause of write-only code?

Question

Monitor.Pulse/All and Monitor.Wait are useful methods, but I'm getting complaints that when using them in large quantities (I have a DSL designer that spits them out by the dozen), the resulting code becomes unreadable. What do you think?

Answer 1

If it's sprinkled all over code that you actually have to read, that could be a problem. Why does it come up so often in the first place? Could the functionality actually be encapsulated somewhere else?

Fundamentally there's nothing wrong with Wait/Pulse - but like everything else in life, if it's used inappropriately it will become a problem. Whether or not your use is inappropriate is hard to tell without seeing the code :(

Answer 2

Sounds like something that should be coded by injection as an aspect. However, my knowledge of the support of AOP in C# is negligible, so I can't offer any more than that.

Answer 3

I'd really advise against this approach - from the MSDN page on PulseEvent:

A thread waiting on a synchronization object can be momentarily removed from the wait state by a kernel-mode APC, and then returned to the wait state after the APC is complete. If the call to PulseEvent occurs during the time when the thread has been removed from the wait state, the thread will not be released because PulseEvent releases only those threads that are waiting at the moment it is called. Therefore, PulseEvent is unreliable and should not be used by new applications. Instead, use condition variables.

Now, Monitor.Pulse might be written using something other than PulseEvent, but the whole concept is pretty flawed - use locks and condition variables properly.