Clever Geek Handbook

Can Pulse & Wait be used? Or is it evil and the reason for writing code?

Monitor.Pulse/All

and Monitor.Wait

- useful methods, but I get complaints that when used in large quantities (I have a DSL designer who spills them out for a dozen), the resulting code becomes unreadable. What do you think?

0


source to share


3 answers


If it sprinkles all the code that you really need to read, that could be a problem. Why does this occur so often in the first place? Could the functionality be encapsulated elsewhere?



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

+1


source


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

A thread wait on a sync object can be temporarily removed from the wait state by using APC in kernel mode and then returned to the wait state after APC completes. If the PulseEvent is called during the time that the thread was removed from the wait state, the thread will not be released because the PulseEvent only releases the threads that are waiting at the moment it is called. Therefore, PulseEvent is unreliable and should not be used by new applications . Use variable conditions instead.



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

0


source


Sounds like something that needs to be injection-coded as an aspect. However, my knowledge of AOP support in C # is negligible, so I cannot suggest anything more.

-1


source






More articles:


All Articles