I used CancellationToken.Register method in order to register a callback that will be executed when a token is canceled. This callback is responsible for notifying TaskCompletionSource<T> that underlying task should be cancelled.

You may say that it is not enough because this code doesn't inform DropNetClient that an action should be cancelled. You are right. However, according to my knowledge DropNet API doesn't provide such a possibility.

It leads to the situation when a task is cancelled but DropNetClient continues processing and finnaly TaskCompletionSource.SetResult method will be executed. This will cause ObjectDisposedException because this method cannot be executed for a disposed task. What can we do in this case?

The first solution is to check if a task is cancelled before calling SetResult method. However, it can still happen that a task will be cancelled after this check but before calling SetResult method.

My proposition is to use methods from TaskCompletionSource.Try* family. They don't throw exceptions for disposed tasks.

I'm aware that it is not a perfect solution because it actually does not cancel processing. However, without modifying DropNet code it is not possible. It the case of my application it is an acceptable solution but it is not a rule.

At some point someone decided to create a new class Algorithm2 derived from BaseAlgorithm. The difference between the new class and the previous one is that Algorithm2 starts an asynchronous operation. A programmer decided to use async/await keywords to handle this scenario. What do you think about this approach? What could possibly go wrong?

Answer #5
I think that the developer who created Algorithm2 doesn't understand well how async/await keywords work. The main problem is that finally block inside Start method will be executed before DoAsyncCalculations method will end calculations. In other words resources will be disposed in the middle of calculations and this will cause an exception. Sequence of events will be as follows:

Start method begins.

SomeObject is created.

InnerStart method begins.

InnerStart method starts an asynchronous operation and uses await to suspend its progress.

This causes that control returns to Start method.

Start method cleanups resources.

When the asynchronous operation is finished InnerStart method continues processing. It tries to use resources, that have been already disposed, what leads to an exception.

It is also not recommended to have async void methods (except event handlers). Ifan async method doesn't return a task it cannot be awaited. It is also easier to handle exceptions if an async method returns a task. For details see also this article.

To fix a problem BaseAlgorithm must be aware of asynchronous nature of calculations. For example InnerStart method can return a task which will be awaited inside try block. However, it also means that synchronous version of InnerStart method in Algorithm1 will have to be changed. It may not be acceptable. Generally, providing asynchronous wrappers for synchronous methods is debatable and should be carefully considered.

In this case, I'll consider to have separated implementations of Template method pattern for synchronous and asynchronous algorithms.

12/07/2015

Question #4
You have to implement a very fast, time critical, network communication between nodes of a distributed system. You decided to use good old sockets. However, you haven't decided yet whether to use TCP or UDP protocol. Which one would you choose and why?

Answer #4
If a speed is the only one important factor, I'd choose UDP. UDP is faster than TCP because it has a smaller overhead. In comparison to TCP it is a connection-less, unreliable protocol that doesn't provide features like retransmission, acknowledgment or ordering of messages.

However, it also means that usage of UDP might be more difficult and will require additional coding in some cases. For example, if we have to assure that sent messages have been delivered. In this case, I'd certainly use TCP.

Finally, there is one more thing in favor of UDP. It provides broadcasting and multicasting. So, if it is required I'd also use UDP instead of TCP.

Recently, I've written a post about integration with Dropbox. This one is also about integration but this time with Skydrive. I spent some time on investigating how to implement this feature in a desktop application. I was even considering to write what I need from the scratch on my own.

Fortunately, it turned out that someone did it for me. I found a nice piece of code prepared by Microsoft. It includes sample applications showing how to do everything step by step. You can download it from github.

06/07/2015

Recently I've found a question about real life scenarios for using rather unknown TaskCompletionSource<T> class. I started thinking where I would use it and very quickly I found a good practical example.

I have a pet project LanguageTrainer that helps me in learning words in foreign languages. Some time ago I added Dropbox support to it. It allows me to export/import list of words to/from Dropbox. I developed it in synchronous way. Now I prefer an asynchronous approach and I want to take advantages of async/await keywords.

The problem is that DropNet library, that makes communication with Dropbox easy, doesn't use async/await. It has asynchronous API but it is callback based. The really easy solution here is to use TaskCompletionSource<T>. Here is an example (simplified). Let's start with the original code that downloads a given file from Dropbox.

02/07/2015

I'd like to share with you the results of 2 surveys regarding my last presentation. The first one was prepared by organizers of the conference. The second one was created by me on SurveyMonkey portal. I placed a link to it on each slide in the lower left corner. It was visible through the whole presentation so anyone with a smartphone could have filled it. The survey was short and consisted of 3 obligatory and 2 voluntary questions.

Let's start with the official survey of the conference. According to it there were ~50 people on my presentation. ~30 said that it was very good, ~18 that it was good and ~2 that it was week. In average it gives 4,56. These are very good results for me, thanks!

My survey looked in the following way:

Question 1 - What is your overall assessment of my presentation on a scale of 1 to 5 (5 - the highest evaluation)?

Question 2 - How do you assess the substantive content of my presentation on a scale of 1 to 5 (5 - the highest evaluation)?

Question 3 - How would you rate my way of presenting on a scale of 1 to 5 (5 - the highest evaluation)?

Question 4 - Name one thing that you remember from my presentation.

Question 5 - This is the place for all sorts of comments, applications and complaints. Each comment will be valuable for me.

I received 8 answers for these questions. Much less than for the previous survey but all the answers were extremely valuable to me. Thanks! Here are details:

1

2

3

4

5

Average

Question 1

1

4

3

4,25

Question 2

4

4

4,50

Question 3

3

5

4,63

I also received a couple of comments that will allow me to be a better speaker in the future:

The demo should have been a little bit longer.

The sample code used during a demo could be more complex.

I should have used a microphone.

I should have spoken slower.

Not all terms used by me were understandable for a layman.

It was nice to read that my presentation was useful and that I showed interesting tools.

As a summary I have to say that these results are a boost of energy for me and an encouragement to be a speaker more often.

Author

Subscribe by Email

Like Me

Follow Me

Subscribe Me

Disclaimer

This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated...