{"id":501,"date":"2013-12-16T13:00:22","date_gmt":"2013-12-16T13:00:22","guid":{"rendered":"http:\/\/writeasync.net\/?p=501"},"modified":"2013-12-02T05:12:42","modified_gmt":"2013-12-02T05:12:42","slug":"building-an-async-exclusive-lock","status":"publish","type":"post","link":"http:\/\/writeasync.net\/?p=501","title":{"rendered":"Building an async exclusive lock"},"content":{"rendered":"

The Monitor<\/code> class<\/a> is useful for establishing critical sections<\/a> in your .NET code. However, this is of no use in asynchronous scenarios for at least two reasons:<\/p>\n

    \n
  1. Monitor<\/code> has thread affinity, meaning the same thread must acquire and release.<\/li>\n
  2. Monitor<\/code> blocks while waiting to acquire — not good for async code paths.<\/li>\n<\/ol>\n

    There is in fact one synchronization primitive in .NET that is thread-neutral and provides nonblocking behavior, SemaphoreSlim<\/code><\/a>. It could be used as follows:<\/p>\n

    \r\n\/\/ Assumes initialization using "new SemaphoreSlim(1, 1)" to provide exclusive\r\n\/\/ access, i.e. number of free slots == number of total slots == 1\r\nprivate async Task DoExclusiveWorkAsync(SemaphoreSlim slimLock)\r\n{\r\n    await slimLock.WaitAsync();\r\n    try\r\n    {\r\n        \/\/ . . . exclusive work here . . .\r\n    }\r\n    finally\r\n    {\r\n        slimLock.Release();\r\n    }\r\n}\r\n<\/pre>\n
    As an educational exercise, I decided I wanted to build my own async exclusive lock. My lock has one bonus feature: it returns a Token<\/code> that can be used to prevent someone who does not own the lock from releasing it. Typically, “It is the programmer’s responsibility to ensure that threads do not release the semaphore<\/a> too many times.” The Token<\/code> is a design fix to prevent this problem from ever occurring in any reasonable situation — at the expense of one additional object allocation.<\/p>\n
    So, putting on my async TDD hat, I got started with the minimal interface…<\/p>\n
    \r\npublic class ExclusiveLock\r\n{\r\n    public ExclusiveLock()\r\n    {\r\n    }\r\n\r\n    public Task<Token> AcquireAsync()\r\n    {\r\n        throw new NotImplementedException();\r\n    }\r\n\r\n    public void Release(Token token)\r\n    {\r\n        throw new NotImplementedException();\r\n    }\r\n\r\n    public abstract class Token\r\n    {\r\n        protected Token()\r\n        {\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
    …and forged ahead with the first unit test (shown after refactoring):<\/p>\n
    \r\n[Fact]\r\npublic void Acquire_completes_sync_then_release_succeeds()\r\n{\r\n    ExclusiveLock l = new ExclusiveLock();\r\n\r\n    ExclusiveLock.Token token = AssertTaskCompleted(l.AcquireAsync());\r\n\r\n    l.Release(token);\r\n}\r\n<\/pre>\n
    You can follow the commit history<\/a> and watch the unit tests spring forth before your eyes. Given the simplicity of the interface, only six tests were needed to get to a complete (single-threaded<\/em>) implementation:<\/p>\n