在没有等待时删除信号量

这里有一个并发性问题:

字符串值用于表示抽象资源，并且只允许一个线程为给定的字符串值工作;但是，如果多个线程的字符串值不同，则可以并发运行。到目前为止，很简单:

private static readonly Dictionary<String,Object> _locks = new Dictionary<String,Object>();
public static void DoSomethingMutuallyExclusiveByName(String resourceName) {
    Object resourceLock;
    lock( _locks ) {
        if( !_locks.TryGetValue( resourceName, out resourceLock ) ) {
            _locks.Add( resourceName, resourceLock = new Object() );
        }
    }
    lock( resourceLock ) {
        EnterCriticalSection( resourceName );
    }
}

但这是次优的:resourceName的域是无界的，_locks可能最终包含数千个或更多的字符串。因此，在没有更多的线程使用特定的resourceName值之后，它的锁定对象应该从字典中删除。

在锁对象被使用后简单地删除它将是一个bug，因为下面的场景(相关代码位于后面)。注意，所有三个线程都有resourceName = "foo"。

• 线程1位于labelC，并且刚刚从_locks字典中删除了resourceName = "foo"，从而删除了resourceLock (#1)。
• 线程2在labelB，因为没有其他线程被锁定在resourceLock (#1)上，它不会在lock( resourceLock等待，而是继续进入EnterCriticalSection。
• 线程3在labelA，因为resourceName = "foo"不在_locks(因为线程1删除了它)，它添加了一个新的实例到_locks，因为这个resourceLock (#2)是一个新的实例，lock( resourceLock )在线程3中不会等待线程2，因此线程2和3都可以在EnterCriticalSection内，具有相同的resourceName值。

public static void DoSomethingMutuallyExclusiveByName(String resourceName) {
labelA:        
    Object resourceLock;
    lock( _locks ) {
        if( !_locks.TryGetValue( resourceName, out resourceLock ) ) {
            _locks.Add( resourceName, resourceLock = new Object() );
        }
    }
    try {
labelB:
        lock( resourceLock ) {
            EnterCriticalSection( resourceName );
        }
    }
    finally {
        lock( _locks ) {
            _locks.Remove( resourceName );
        }
labelC:
    }
}

我最初用自己的小技巧解决了这个问题:

class CountedLock {
    public Int32 Count;
}
private static readonly Dictionary<String,CountedLock> _locks = new Dictionary<String,CountedLock>();
public static void DoSomethingMutuallyExclusiveByName(String resourceName) {
labelA:        
    CountedLock resourceLock;
    lock( _locks ) {
        if( !_locks.TryGetValue( resourceName, out resourceLock ) ) {
            _locks.Add( resourceName, resourceLock = new CountedLock() { Count = 1 } );
        }
        else {
            resourceLock.Count++; // no need for Interlocked.Increment as we're already in a mutex code block
        }
    }
    try {
labelB:
        lock( resourceLock ) {
            EnterCriticalSection( resourceName );
        }
    }
    finally {
        lock( _locks ) {
labelD:
            if( --resourceLock.Count == 0 ) {
                _locks.Remove( resourceName );
            }
        }
labelC:
    }
}

这就解决了问题。假设这三个线程位于与之前相同的位置:

• 线程1没有从_locks中删除它的resourceName resourceLock值，因为线程2也引用了与线程1相同的resourceLock，所以当线程1处于labelD时，相关的计数是2(当线程1达到labelC时，计数变为1)。
• 线程2继续进入临界区，因为它在线程3之前到达。
• 如果线程3(在labelA)到达TryGetValue，而线程2仍然在临界区，那么将看到它的resourceName="foo"仍然在_locks字典中，因此获得与线程2相同的实例，因此它将在labelB等待线程2完成。
• 所以这有效!

但我猜你现在在想:

"所以你有一个锁与一个相关的计数…听起来你好像重新发明了信号量。不要重新发明轮子，使用System.Threading.Sempahore或SemaphoreSlim。

确实，所以我改变了我的代码使用SemaphoreSlim - SemaphoreSlim实例有一个内部Count值，它是允许进入的线程数(与当前"内部"信号量的线程数相反-这与我的CountedLock示例在上一个示例中的工作方式相反):

private static readonly Dictionary<String,SemaphoreSlim> _locks = new Dictionary<String,SemaphoreSlim>();
public static void DoSomethingMutuallyExclusiveByName(String resourceName) {
labelA:
    SemaphoreSlim resourceLock;
    lock( _locks ) {
        if( !_locks.TryGetValue( resourceName, out resourceLock ) {
            _locks.Add( resourceName, resourceLock = new SemaphoreLock( initialCount: 1, maxCount: 1 ) );
        }
    }
labelB:
    resourceLock.Wait(); // this decrements the semaphore's count
    try {
        EnterCriticalSection( resourceName );
    }
    finally {
        lock( _locks ) {
            Int32 count = resourceLock.Release(); // this increments the sempahore's count
            if( count > 0 ) {
                _locks.Remove( resourceName );
                resourceLock.Dispose();
            }
labelC:
        }
    }
}

…但是发现bug!

考虑这个场景:

线程1位于labelC，并且刚刚删除并处置了它的resourceLock (#1)实例。线程2在labelB(在调用Wait之前)。它获得了与线程1相同的SemaphoreSlim resourceLock (#1)实例的引用;而是因为Wait方法被调用线程离开后lock( _locks ) labelA下这意味着有一个小,但现存的,机会之窗,线程2将调用resourceLock (#1).Wait()(忽略可能ObjectDisposedException),而线程3(目前labelA)将输入TryGetValue并实例化一个新的实例的SemaphoreLock (#2) resourceName相同,但是因为线程2和3的区别信号情况下,他们都将可能同时进入临界区。

你可以建议:

当你在labelA

下的lock( _locks )块内时，你应该想办法减少信号量

…除了SemaphoreSlim类没有公开任何Decrement方法。可以调用.Wait(0)，使其立即返回，因此我的代码看起来像这样:

[...]
labelA:
    SemaphoreSlim resourceLock;
    lock( _locks ) {
        if( !_locks.TryGetValue( resourceName, out resourceLock ) {
            _locks.Add( resourceName, resourceLock = new SemaphoreLock( initialCount: 1, maxCount: 1 ) );
        }
        resourceLock.Wait( 0 );
    }
labelB:
    resourceLock.Wait();
[...]

…但这行不通。Wait(Int32)状态的文档(重点是我的):

如果线程或任务在调用Wait(Int32)时被阻塞，并且由millisecdstimeout指定的超时时间过期，线程或任务不会进入信号量，并且CurrentCount属性不递减。

…这个理论到此为止。即使它确实有效，在同一个线程中调用Wait两次可能会减少两次计数，而不是一次。

那么，是否有可能有一个由互斥体保护的临界区，以某种方式"知道"何时不再需要它们?