{"id":56019,"date":"2012-02-12T08:16:08","date_gmt":"2012-02-12T08:16:08","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/pfxteam\/2012\/02\/12\/building-async-coordination-primitives-part-5-asyncsemaphore\/"},"modified":"2012-02-12T08:16:08","modified_gmt":"2012-02-12T08:16:08","slug":"building-async-coordination-primitives-part-5-asyncsemaphore","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/building-async-coordination-primitives-part-5-asyncsemaphore\/","title":{"rendered":"Building Async Coordination Primitives, Part 5: AsyncSemaphore"},"content":{"rendered":"

In my last few posts, I covered building an AsyncManualResetEvent<\/a>, an AsyncAutoResetEvent<\/a>, an AsyncCountdownEvent<\/a>, and an AsyncBarrier<\/a>.  In this post, I’ll cover building an AsyncSemaphore class.<\/p>\n

Semaphores have a wide range of applicability.  They’re great for throttling, for protected access to a limited set of resources, and more.  There are two public semaphore types in .NET: Semaphore (which wraps the Win32 equivalent) and SemaphoreSlim (which provides a lightweight counterpart built around Monitors).  Here we’ll build a simple async version, with the following shape:<\/p>\n

\n

public class<\/font> AsyncSemaphore<\/font>
{
    public<\/font> AsyncSemaphore(int<\/font> initialCount);
    public<\/font> Task<\/font> WaitAsync();
    public void<\/font> Release();
}<\/font><\/p>\n<\/blockquote>\n

The member variables we’ll need look almost exactly the same as what was needed for the AsyncAutoResetEvent<\/a>, and for primarily the same reasons.  We need to be able to wake individual waiters, so we maintain a queue of TaskCompletionSource<bool> instances, one per waiter.  We need to keep track of the semaphore’s current count, so that we know how many waits can complete immediately before we need to start blocking.  And as we’ll see, there’s the potential for a fast path, so we maintain an already completed task that we can use repeatedly when the opportunity arises.<\/p>\n

\n

private readonly static<\/font> Task<\/font> s_completed = Task<\/font>.FromResult(true<\/font>);
private readonly<\/font> Queue<\/font><TaskCompletionSource<\/font><bool<\/font>>> m_waiters = new<\/font> Queue<\/font><TaskCompletionSource<\/font><bool<\/font>>>();
private<\/font> int<\/font> m_currentCount;<\/font>
<\/p>\n<\/blockquote>\n

The constructor will just initial the count based on the caller’s request:<\/p>\n

\n

public<\/font> AsyncSemaphore(int<\/font> initialCount)
{
    if<\/font> (initialCount < 0) throw new<\/font> ArgumentOutOfRangeException<\/font>(“initialCount”<\/font>);
    m_currentCount = initialCount;
}<\/font>
<\/p>\n<\/blockquote>\n

\n

public<\/font> Task<\/font> WaitAsync()
{
    lock<\/font> (m_waiters)
    {
        if<\/font> (m_currentCount > 0)
        {
            –m_currentCount;
            return<\/font> s_completed;
        }
        else<\/font>
        {
            var<\/font> waiter = new<\/font> TaskCompletionSource<\/font><bool<\/font>>();
            m_waiters.Enqueue(waiter);
            return<\/font> waiter.Task;
        }
    }
}<\/font><\/p>\n<\/blockquote>\n

The Release side of things will also look very familiar.  If there are any waiters in the queue, we dequeue one and complete its TaskCompletionSource<bool>, but we do so outside of the lock, for the same reason we did so with AsyncAutoResetEvent.  If there aren’t any waiters, then we simply increment the count.<\/p>\n

\n

public void<\/font> Release()
{
    TaskCompletionSource<\/font><bool<\/font>> toRelease = null<\/font>;
    lock<\/font> (m_waiters)
    {
        if<\/font> (m_waiters.Count > 0)
            toRelease = m_waiters.Dequeue();
        else<\/font>
            ++m_currentCount;
    }
    if<\/font> (toRelease != null<\/font>)
        toRelease.SetResult(true<\/font>);
}<\/font><\/p>\n<\/blockquote>\n

Next time, we’ll take a look at how to use such an AsyncSemaphore to implement a scoped mutual exclusion locking mechanism<\/a>.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

In my last few posts, I covered building an AsyncManualResetEvent, an AsyncAutoResetEvent, an AsyncCountdownEvent, and an AsyncBarrier.  In this post, I’ll cover building an AsyncSemaphore class. Semaphores have a wide range of applicability.  They’re great for throttling, for protected access to a limited set of resources, and more.  There are two public semaphore types in […]<\/p>\n","protected":false},"author":360,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7908],"tags":[7925,36,7916,7909,7912],"class_list":["post-56019","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pfxteam","tag-net-4-5","tag-async","tag-coordination-data-structures","tag-parallel-extensions","tag-task-parallel-library"],"acf":[],"blog_post_summary":"

In my last few posts, I covered building an AsyncManualResetEvent, an AsyncAutoResetEvent, an AsyncCountdownEvent, and an AsyncBarrier.  In this post, I’ll cover building an AsyncSemaphore class. Semaphores have a wide range of applicability.  They’re great for throttling, for protected access to a limited set of resources, and more.  There are two public semaphore types in […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/56019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/360"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=56019"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/56019\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=56019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=56019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=56019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Our WaitAsync method will also be reminiscent of the WaitAsync we wrote for AsyncAutoResetEvent<\/a>.  We take a lock so as to ensure all of the work we do happens atomically and in a synchronized manner with the Release method we’ll write shortly.  Then, there are two possible paths.  If the current count is above zero, there’s still room left in the semaphore, so this wait operation can complete immediately and synchronously; in that case, we decrement the count and we return the cached completed task (this means that waiting on our semaphore in an uncontended manner requires no allocations).  If, however, the current count is 0, then we create a new TaskCompletionSource<bool> for this waiter, add it to the list, and return its Task to the caller.<\/p>\n