Async Tip: why you should avoid void

Wednesday, March 15, 2017

Async Tip: why you should avoid void The guideline to prefer async method which return Task over async method that return void is quite known, but why should you follow the guideline? Code Snippet public async void NotRecomendedAsync() {     // do something     await SomeCodeWhichMayThrowAsync();     // do something }   public async Task RecomendedAsync() {     // do something     await SomeCodeWhichMayThrowAsync();     // do something } The first obvious reason to use the guideline is testability. When you return void the test don’t really know when it is right time to check...
no comments

Rx Challenge #11–Solution

Thursday, September 15, 2016

Rx Challenge #11–Solution You can find the solution for Challenge 11 below. Previous challenges available here. The following code snippet implement the base functionality which is similar to the functionality of SemaphoreSlim. Code Snippet public class AsyncLock {     private int _counter = 0;     private readonly int _limit;     // semantic Task     private ConcurrentQueue<TaskCompletionSource<object>> _tcsQueue =         new ConcurrentQueue<TaskCompletionSource<object>>();       #region Ctor       /// <summary>     /// Initializes a new instance of the <see cref="AsyncLock"/> class.     /// </summary>     /// <param name="limit">The limit.</param>     public AsyncLock(int limit)     {         _limit = limit;     }       #endregion // Ctor       #region WaitAsync  ...
no comments

Rx Challenge #11

Thursday, September 8, 2016

Rx Challenge #11 This challenge is practice of building something already exists, by your own. The challenge is to build async lock similar to the functionality of SemaphoreSlim WaitAsync / Release. You can check this post for the functionality of SemaphoreSlim. You can consider the following building block for this challenge: - Concurrent Collection - Interlocked - TaskCompletionSource You can validate your solution against this Test Code Snippet public async Task AsyncLock_Test() {     // arrange     const int LIMIT = 3;     var gate = new TaskCompletionSource<object>();     var barrier = new CountdownEvent(LIMIT);     var asyncLock =...
no comments

Rx Challenge #10 (Solution): DistinctUntilChanged with expiration period

Friday, September 2, 2016

Rx Challenge #10 (Solution): DistinctUntilChanged with expiration period The solution for the DistinctUntilChanged challenge is: Code Snippet public static IObservable<TSource> DistinctUntilChanged<TSource, TKey, TPeriod>(     this IObservable<TSource> source,     Func<TSource, TKey> keySelector,     IEqualityComparer<TKey> comparer,     IObservable<TPeriod> distinctPeriod) {     var result = source.Publish(hot =>     {         var distinct = hot.TakeUntil(distinctPeriod)                           .DistinctUntilChanged(keySelector, comparer)                           .Repeat();         return distinct;     });     return result; }   The idea is to cancel the district stream after a period and resume the subscription (repeat).   You can use the following convenient overloads: Code Snippet public static IObservable<TSource> DistinctUntilChanged<TSource>(     this IObservable<TSource>...

Rx Challenge #9: Execute Async Until [Solution]

Tuesday, August 30, 2016

Rx Challenge #9: Execute Async Until Challenge #9 was about implementing a pattern where you have to keep sending async message until you will get notification which approve that the message is handled by the other side. see the full detail at the Challenge at this post. Simple scenario For the simple scenario of you calling service and retry sending, according to it’s response. You can use the following pattern. Code Snippet private static async Task VerySimpleScenario() {     var delay = Observable.Timer(TimeSpan.FromSeconds(1));     var noDelay = Observable.Return(1L);     var xs = Observable.FromAsync(() => ExecSimpleAsync(1))...

Rx Challenge #10: DistinctUntilChanged with expiration period

Friday, August 19, 2016

Rx Challenge #10: DistinctUntilChanged with expiration period This challenge is DistinctUntilChanged  cancellation after a period. When having event stream which may produce items in a row and then be idle for a period. You may want to get item after a period even those it identical the the previous one.   On challenge you need to construct it using composition of existing Rx’s operators. It can be formulate into the following pattern: Code Snippet public static IObservable<T> DistinctUntilChanged<T>(     this IObservable<T> source,     TimeSpan distinctPeriod) {     // TODO: your code }   ...
no comments

Rx Challenge #9: Execute Async Until

Tuesday, August 16, 2016

Rx Challenge #9: Execute Async Until This time the challenge is for implementing a pattern where you have to keep sending async message until you will get notification which approve that the message is handled by the other side. The idea is to verify that the message was handled by other side without keeping open connection and waiting for response (which already implement by the TCP protocol). This pattern can be useful on many scenarios, For example, any queue mechanism like Service Bus, Rabbit MQ, etc. Using this pattern you can keep sending the message using predefine interval...

Semaphore Slim and Async

Semaphore Slim and Async On this post I will focus on async waiting on Semaphore (using SemaphoreSlim). In general .NET is having 2 Semaphore implementations: - Semaphore which is the legacy implementation (but support cross process operations) - SemaphoreSlim which is lightweight version. It bring some performance improvements but it don’t support cross process operation. this post will focus on SemaphoreSlim WaitAsync API. Let start analyzing the following code snippet, think what’s wrong with it: Code Snippet private static SemaphoreSlim _gate = new SemaphoreSlim(4); static void Main(string args) {     for (int i = 0;...
no comments

Demystify Async and Await (Part 1 of 2)

Tuesday, March 29, 2016

Demystify Async and Await (Part 1 of 2) After seeing so many confusion speed abroad the industry, I had came to conclusion to write this post and demystify the behavior of async and await.   To many people is having to many wrong conceptions and theories about the functionality of async and await. It lead to great confusion and bad practices. In order to explain async and await I must go back to the basic and demystify Task.   Part 1 of this 2 part series will explain what really is Task and the confusion almost everybody...
no comments

Service Fabric Concept, Guidelines and Patterns #6-Deadlock

Saturday, February 20, 2016

Service Fabric Concept, Guidelines and Patterns #6-Deadlock this post is part of the Service Fabric’s series which covers Service Fabric’s concept, guidelines and common patterns. at this post we will discuss potential deadlock and good practice for avoiding it.   The idea for this post came while speaking with Jeffrey Richter from the Service Fabric team. When would you get deadlock on Service Fabric’s Actor Model? deadlock occurs when Actor A calls instance of Actor B and different call for Actor B (not recurrent) call the same instance of Actor A. A ---->...