This seems to be my favorite geek subject, but I have to tell you a success story using Ian Griffith's Timed Lock struct with my enhancement.
To recap, when you fail to acquire a lock on an object because another thread already has one, my enhancement allows you to see the stack trace of the blocking thread. Well the other day, I was running a suite of unit tests against a socket server I was building when one of the tests failed with a ThreadTimeoutException. Looking at the stack trace, I found the line of code where another thread was...
Wow! After posting my update to the TimedLock class entitled TimedLock Yet Again Revisited..., Ian Griffiths posts this gem which outlines a solution to one of the problem's with my approach to keeping a stack trace.
The problem is that my code acquires a stack trace every time it acquires a lock just in case another thread fails to acquire a lock. The purpose of this action is so that we can examine the stack trace of the blocking thread to find out why we couldn't acquire a lock. This can be a big performance cost in some situations.
Ian received...
In an earlier post, I updated the TimedLock class (first introduced in this post) to allow the user to examine the stack trace of the thread that is holding the lock to an object when the TimedLock fails to obtain a lock on that object. This assumes that the blocking lock was obtained using the TimedLock. Ian Griffiths pointed out a few flaws in my implementation and I promised I would incorporate his feedback and revise the code.
Since that time, Ian revisited the TimedLock based on comments he recevied and changed it to be a struct in both...
In an earlier blog entry, I asked the question if it made sense to add code in a debug version of the TimedLock class (written by Ian Griffiths in this post and commented on by Eric Gunnerson in this post) to store the stack trace when acquiring a lock on an object so that if another thread blocks an attempt to acquire a TimedLock, we can discover the StackTrace of the blocking thread.
Well I stopped asking questions and started writing answers. I update the TimedLock class with stack trace tracking and also wrote an NUnit test that demonstrates the...
Found this on Eric Gunnerson's (PM for the C# compliler team) blog. It's an interesting approach to get a lock statement with a time out. It would be nice to perhaps add a timeout syntax to the lock statement in C#. Maybe it would look like this:
object obj = new object();
int milliseconds = 10000;
try
{
lock(obj, milliseconds)
{
//Do something with obj
}
}
catch(LockTimeOutException exception)
{
//Handle exception
}
One thought I had, and let me know if I'm off base, but it seems we could add debug code to Ian...