Task.Run vs. Task.Factory.StartNew (Part 2)


Task.Run vs. Task.Factory.StartNew (Part 2) This post continue the previous post about the differences between Task.Run vs. Task.Factory,StartNew. In the previous part I was speaking about the scheduling aspect, on this part I will spot the async await behavior.   Check the following code snippet and think what can go wrong: Code Snippet private async Task ExecuteAsync() {     var sw = Stopwatch.StartNew();     await Task.Factory.StartNew(async () =>         {             Console.WriteLine("Start section");             await Task.Delay(1000);             Console.WriteLine("End section");         });     Console.WriteLine(sw.Elapsed); }   What output will it produce? Will it be something like the following output: ...

Task.Run vs. Task.Factory.StartNew (Part 1)


Task.Run vs. Task.Factory.StartNew (Part 1) This post will focus on the key difference between Task.Run and Task.Factory.StartNew. For you can drill down into more details on this excellent post by Stephen Toub. In general you have to know that Task.Run is more restricted version of Task.Factory.StartNew. Task.Run sets default which fit for most common cases. Task.Factory.StartNew is there for advance scenarios.   in general Task.Run is equivalent to: Code Snippet Task.Factory.StartNew(someAction,                 cancellationToken,                 TaskCreationOptions.DenyChildAttach,                 TaskScheduler.Default);   Why should you care about it and how can it be used right?...
no comments

NuGet Extensions


Click Dimensions open source the first preview of NuGet Extensions tool which is used internally for managing projects which deployed as NuGet. The development process of solution which is using NuGet of internal component is not easy when Ii t come to debug and upgrade. Consider the case when you’re debugging the application and you find out that there is a bug on the infrastructure. In case when the infrastructure is consume via NuGet you will have to: - Fix the bug. - Pack new version of the infrastructure (NuGet). - Update the application. - Re-test it with the...
no comments

Rx Challenge #11–Solution


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


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


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]


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


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