The issue was that it’s categorized as a snippet which really is a small amount of code that’s self explanatory. Snippet and Helper categories don’t offer a usage example input. Your code might fit into the Extension category more. I’ve chosen to make the usage example optional for all categories. You should be able to edit one in now.
I came up with an alternate solution this afternoon to allow me to use the standard lock(…) and Monitor.X functionality while enabling the implementation of Wait and Pulse. It requires the locking object to be of a specific type (MicroLock) which contains the AutoResetEvent required. I’ve added it to the NetMf.CommonExtensions at http://netmfcommonext.codeplex.com/ and will post at fezzer once its back up from maintenance.
It makes the wait and pulse almost identical to that which you would expect, the only difference is calling them using MonitorMicro rather than Monitor.
Example usage:
public class BasicLockExample
{
private object _locker = new MicroLock();
public void Run()
{
while (true)
{
lock (_locker)
{
if (MonitorMicro.Wait(_locker, 1000))
{
Debug.Print("Signalled OK");
}
else
{
Debug.Print("Timout waiting");
}
}
}
}
public void DoWork()
{
lock (this._locker)
{
MonitorMicro.Pulse(_locker);
}
}
@ Ross - reply to response #14 on 10/31.
Thanx for the response. I can’t speak to how the AutoResetEvent works (something to research) so I will accept your statements as given. If I understand your point (not entirely, but I think I get the gist of it), then I see why a non static class is needed.
Thanx again,
Ralf
@ William - reply to posting on 11/1
That’s what I’m seeing between your comments and Ross’s. I appreciate the input. As for the performance considerations, that was more thinking out loud than anything else. As I said, my preference is for making a static calls - Monitor2.Wait(lockerObj), Monitor2.Pulse(lockerObj) - rather than instance syntax for something like this as simply a matter of style.
I’m not used to working in an environment where resources are limited as they are in the microprocessor arena and I’m just pondering the practical implications of that. And you’re right. There is a time and a place for these sorts of optimizations and more often than not (at least in the Desktop/Server world), proper design is far more important for getting good performance than worrying about a couple of bytes used here or there or CPU cycles consumed, etc.
Thanx,
Ralf
@ Ralf.
I agree it would be better to use same static interface as Monitor. However, monitor is special because it has thread affinity and would be difficult to do in managed code. I suppose you might be able to do it with spin locks, interlocks, and some thread local storage, but not sure would be worth it. So leveraging the existing monitor and wrapping some additional usage is a fair trade off imo. Its not that much code, so I am clueless why they did not just add a couple methods. I guess most MF don’t use wait/pulse so did not make the list. I would guess it is on the todo.