Task.Delay Challenge Solution

Friday, April 21, 2017

Task.Delay Challenge Solution This post suggest solution to the Task.Delay challenge. If you haven’t read the Task.Delay challenge you can find it here. In nutshell the challenge was about making Task.Delay like functionality which is test-able (using IScheduler for having virtual time). In order to support virtual time I will use Rx’s stream (which is also awaitable). The original Task.Delay is actually having 2 different completion path: - Complete by time. - Complete as result of cancellation token event. The general idea of the solution is to have 2 Rx’s streams one for each completion path: - Timer...
no comments

Task.Delay Challenge

Friday, April 14, 2017

Task.Delay Challenge Task.Delay can be useful in many scenarios, for example: periodic execution.  Traditionally periodic execution done by using Timer API. Periodic execution with Task.Delay is easy for debug and better for maintain. The following code show the pattern: Code Snippet private async Task PeriodicJobAsync(CancellationToken token) {     var duration = TimeSpan.FromSeconds(5);     while (!token.IsCancellationRequested)     {         try         {             await Task.Delay(duration, token);         }         catch (OperationCanceledException) { }           // Process the job     } } The problem start when you want to test the code without waiting the real-world duration.   The challenge...
no comments

SDP Teaser

Tuesday, April 4, 2017

This is a short teaser for what I’m planning to talk about in the next upcoming SDP conference. If you happened to be in Israel on May 2017 you can still register to the talk. The audience for this session expected to have prior knowledge about TPL,  async / await and parallel programming in general. On this full day workshop I will focus on the less familiar aspects and patterns.   Beyond Async And Await Planed Agenda * Task from different angle * Task.Run vs Task.Factory.StartNew * async / await drill down and custom awaitable * Some...

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 #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

Semaphore Slim and Async

Tuesday, August 16, 2016

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