Category: Multi Threaded

We saw the Asynchronous Programming Model (APM) which fires the method(s) inside a delegate using BeginInvoke and EndInvoke. BeginInvoke executes a single method inside a delegate asynchronously. if we desire to retrieve the result of the delegate (whenever the delegate points to a function which returns a value) we would use the EndInvoke. we could also use the EndInvoke in order to wait for the delegate function to be completed (like wait, or join). in order to use the EndInvoke mechanism we require the IAsyncResult. the IAsyncResut is an object which looks a bit like the Task object. it can help us to check whether the delegate has completed or not. whenever we call the EndInvoke we pass the IAsyncResult as a parameter. Another strategy could be to assign a CallBackMethod which will be executed after the BeginInvoke delegate has been completed (without blocking our code). the CallBackMethod  we write accepts the IAsyncResult as a parameter (which is automatically sent be the .NET framework [dependency injection]) so we could run the EndInvoke inside the CallBackMethod, or just check the state of the delegate. we saw that if we want to run all of the methods inside a delegate asynchronously we could write a foreach loop which iterates over the delegate methods using the GetInvocationList and fires them using the BeginInvoke. we also saw that we could pass any type of argument to the BeginInvoke method which will be passed to the IAsyncResult.AsyncState property

More topics covered:

• Delegate class. the base of MultiCastDelegate class
• DynamicInvoke
• Task implements IAsyncResult 
• BeginInvoke runs on a background thread
• BeginInvoke could be executed only on a single delegate method
• EndInvoke could be executed on a specific delegate only once
• @object

Links:

• Class code: delegate
• Class code: Async-Await
• Youtube lecture code
• BeginInvoke EndInvoke – MSDN link
• MultiCastDelegate – MSDN link
• AsyncCallback method – MSDN link
• Home Work!
• Lesson Summary Video!

We saw the Task.Run (.NET 4.5) and the Task.Factory.StartNew which are a short and simple way to create and start a task (the difference between them is that Task.Factory.StartNew supports LongRunning operations [non threadpool threads]).we talked about Task.ContinueWith. the Continue-with creates a continuation task and executes it after the first task is completed. The continuation task is executed or not based on a set of specified conditions provided by the  TaskContinuationOptions enum, for example: continue to the next task only if the previous task completed successfully, etc. tasks have a built-in mechanism for cancellation called cancellation token (part of the CancellationTokenSource). the cancellation token is a struct which enables cooperative cancellation between tasks. When the owning object calls CancellationTokenSource.Cancel, the IsCancellationRequested property is set to true. this means that in the tasks that we write we should check the cancellation token state.  if the state is cancelled- we could decide how to proceed, for example: quit the method, ignore, throw OperationCancelledException (using built-in ThrowIfCancellationRequested method) , etc. we saw that whenever an exception occur inside a task- it is nested inside an AggregationException. since tasks are running on a background threads- the exception thrown inside a tasks does not “crash” the program. however, if we try to Wait for a faulted task or retrieve the Result from a faulted task: AggregationException will be thrown (which could crash our program, if not handled). so the best approach will be to try-catch the Wait or to check whether the task is faulted or not, then if it is faulted- use the Task.Exception.Handle method

More topics covered:

• Task.ContinueWith should keep the same return value
• Task.ContinueWith creates a parent-child tasks
• In the Task.ContinueWith, The child task will be executed even if the parent task throws an exception
• ThrowIfCancellationRequested throws an exception only if the token was cancelled
• Dependency injection

Links:

• Class code: tasks
• C# CancellationToken- MSDN link
• C# ContinueWith – MSDN link
• C# TaskContinuationOptions – MSDN link
• C# AggregateException – MSDN link
• Dependency injection – nice article
• Project Home Work: write the LoginService– come on, do it!
• Home Work – Tasks
• Lesson Summary Video!

We talked about WaitHandle class in .NET which is used to synchronize between asynchronous work.  Two important classes which derive from WaitHandle are: Manual Rest Event and Auto Rest Event. these classes are used in order to allow one thread to wait in a specific location in the code (WaitOne) until  a different thread completes his work (Signal). it’s quite similar to Wait and Pulse (or PulseAll) but the difference is that you do not need a locking object and you don’t need a critical section. you simply wait-one and signal without any constrains. we made an example in which there are threads which should add drawing to a web page, but they all should wait for the page to be loaded first, before they could start drawing. therefor all of these threads will be in a WaitOne state- till the loading page thread finished and call the Signal. The difference between manual reset event and auto reset event is that in manual reset event- after the signal has occurred- all the threads can pass the WaitOne “gate” (even threads reaching the WaitOne in a later point in time) in oppose to auto reset event, in which only one thread can pass the WaitOne “gate”. it means that we have to call the Signal each time we desire to allow one waiting thread to pass the WaitOne “gate” (similar to Wait-Pulse)

We explored the Task type. what is a task?  answer: “A task is an object that represents some work that should be done. The task can tell you if the work is completed and if the operation returns a result, the task gives you the result. Tasks class also let you create threads and run them asynchronously (by default uses the ThreadPool threads)”. we saw how to create tasks, start task, wait for task, retrieve task result, wait for all-tasks, and wait for any task (in a list of tasks)

More topics covered:

• WaitOne( millisecond)  will proceed after the time limit, even if the “gate” is closed!
• ManualRestEvent can be set to Signaled in the ctor
• For non-threadpool use: TaskCreationOption . LongRunning
• Task Parallel Library (TPL) introduction
• Tasks uses background thread
• Cancellation token introduction
• Task.RunSynchronously 
• Task.Result
• Project start-up

Links:

• Class code: WaitHandle
• Class code: Tasks
• Class code: Final Project demo code
• C# Tasks – MSDN link
• C# WaitHandle – MSDN link
• C# Auto Reset Event – MSDN link
• C# Manual Reset Event – MSDN link
• C# TPL – MSDN link
• Home Work (1): in the project, write the LoginService
• Home Work (2)
• Lesson Summary Video!

We encountered the dilemma of using multi-threaded solution vs. single threaded solution: are we reducing the execution time or not? … to answer this question we should test how long does it take us to spawn new threads? and if we sum up all of the initialization threads time and the execution time – does it take longer than a single thread? if so- we should use the multi-threaded solution, otherwise we should use a single threaded solution. We learned about the ThreadPool collection and saw that “borrowing” a thread from the ThreadPool saves us a lot of time! since we do not need to initialize the thread (it is automatically ready-to-go). however, we should not use ThreadPool threads for long operations, and also beware not to exhaust this resource.
We saw that multi threaded programming might cause an exception when few threads try to add/remove items from a List. why? because if one thread is trying to add an item to the list, while another thread is trying to remove an item from the list – it crashes the program. What could be the solution?  Answer: (1) use .NET Concurrent collections which are Thread-Safe (meaning that they support multi-thread access). these collections limits the access to a resource for only one thread at a time. it’s an easy-to-use solution but the down side is that we always pay the cost of longer access time (because of the locking mechanism) (2) use Monitor.Enter and Monitor.Exit: these commands block a certain code-block (critical section) and do not allow more than one thread to enter this code-block at the same time. we saw that if we forget to call Monitor.Exit then the lock is not released and a deadlock scenario may occur (causing the thread to get “stuck”). Finally we saw that instead of using Monitor.Enter and Monitor.Exit– we can simply use lock (key) { … }, which “behind the scene” calls the Monitor.Enter and Monitor.Exit (using a try-finally block). still there are some differences between Monitor and lock (i.e. Monitor.TryEnter)

More topics covered:

• Thread states flow
• Stopwatch
• SyncRoot
• Every object can be used as a key
• We need different locks for different resources
• Beware of using instance lock for static resource
• System.Collections.Concurrent namespace
• System.Collections.Concurrent.ConcurrentDictionary
• ArrayList.Synchronized(new List<int>());
• ThreadPool.QueueUserWorkItem

Links:

• Class code: Previous HW solution
• Class code: Threads lock and collections
• Class code: Dictionary exercise solution
• ThreadStates – MSDN link
• ThreadPool – MSDN link
• ThreadPool – nice article
• Concurrent Collections – MSDN link
• C# Monitor – csharp-corner
• Monitor vs. Lock – stackoverflow
• Home Work!
•  Lesson Summary Video!

We learned about multi threaded programming in C#. we understood that every program is actually a process which contains threads. there are foreign threads and background threads. there should be at least one foreign thread running in order to keep the process alive. in console application, our program runs in the main thread, which of course is a foreign thread. we can create our own customized threads and start them using the Start command. we saw ThreadStart delegate which does not contain any parameters, and ParameterizedThreadStart delegate which contains an object parameter. we saw we can Abort a thread, and we can also Join a thread to wait for its execution to be completed.

More topics covered:

• Context switch
• Thread.Sleep, Thread.Yield
• Thread.ManagedThreadId
• Storing threads in a List<Thread>
• ThreadPool concept

Links:

• Class code: Previous HW solution
• Class code: Previous HW etgar
• Class code: Thread basics
• Class code: Thread join + parameterized
• Threads – MSDN link
• Threads – tutorial points
• Home Work!
•  Lesson Summary Video!