haacked / timedlock

A Lock structure with timeout and stack traces in case of deadlock

TimedLock

A Lock structure with timeout and stack traces in case of deadlock

Here's the original blog post that introduces the concept from Ian Griffiths.

• http://www.interact-sw.co.uk/iangblog/2004/03/23/locking

I wrote a series of blog posts trying to improve on this.

• A lock statement with timeout
• A TimedLock success story
• TimedLock Revisited
• TimedLock Yet Again Revisited...
• TimedLock with stack traces strikes back

I finally moved the code into this Repository.

Usage Example

try
{
    TimedLock timeLock = TimedLock.Lock(obj);
    //Thread safe operations
    timeLock.Dispose();
}
catch(LockTimeoutException e)
{
    Console.WriteLine("Couldn't get a lock!");
    StackTrace otherStack = e.GetBlockingThreadStackTrace(5000);
    if(otherStack == null)
    {
        Console.WriteLine("Couldn't get other stack!");
    }
    else
    {
        Console.WriteLine("Stack trace of thread that owns lock!");
    }
}

Note, you'll only ever get the other stack trace in DEBUG builds.

timedlock's Issues

How to define my own lock block ?

My way to use lock is like following

lock (obj)
{
DoIt();
}

How can I use your project to do the same thing?
I have read the example, but I can't figure out how to use.

try
{
TimedLock timeLock = TimedLock.Lock(obj);
//Thread safe operations
timeLock.Dispose();
}

Thanks for helping me.

Lock(seconds) converts to a TimeSpan that is immediately converted to Milliseconds.

Looking at the reference source for Monitor.Try() you can see that internally it uses milliseconds and that it converts a TimeSpan to Milliseconds.

Therefore the Lock() overload that creates a TimeSpan from the seconds parameter causes a bunch of wasted cycles as it creates a timespan that is immediately converted to milliseconds.

https://referencesource.microsoft.com/#mscorlib/system/threading/monitor.cs

Lock(seconds

Looking at the reference source for Monitor.Try() you can see that internally it uses milliseconds and that it converts a TimeSpan to Milliseconds.

Therefore the Lock() overload that creates a TimeSpan from the seconds parameter causes a bunch of wasted cycles as it creates a timespan that is immediately converted to milliseconds.

https://referencesource.microsoft.com/#mscorlib/system/threading/monitor.cs