.Net Multi Threading Interview Questions

Single Thread Model

 In this type of thread model only one thread is used to run the process remaining process needs to wait . The other processes must wait for the current execution of the thread to complete. The main disadvantage of this model is system idle time and long time to complete of small task.

Apartment Thread Model (Single Thread Apartment Model)

In this model we can have multiple threads executing with in an application. In single threaded apartment (STA) each thread is isolated in a separate apartment underneath the process. Each process can have multiple apartments that can share data between these apartment. Here the application is responsible for defining the time duration of each thread execution under these apartment. All requests are serialized through the Windows message queue such that only a single apartment is accessed at a time and thus only a single thread will be executing at any one time. Advantage of this model over single threaded is that multiple tasks can be processed at one time on the users request instead of just a single user request. This model still lack in performance as it is serialized thread model, task will be performed one after another.

Multi Thread Apartment Model (Free thread Apartment Model)

The Multi Threaded Apartment (MTA) model has a single apartment created underneath the process rather than multiple apartments. This single apartment holds multiple threads rather than just a single thread. No message queue is required because all of the threads are a part of the same apartment and can share. These applications typically execute faster than single threaded and STA because there is less system overhead and can be optimized to eliminate system idle time. These types of applications are complex to program as thread synchronization should be provided as part of the code to ensure that threads do not simultaneously access the same resources. A race condition can occur for the shared resource. Thus it is completely necessary to provide a locking system. When locking is provided this can result in a deadlock of the system.

Read More

The idea for making a pool of threads on the .NET framework level comes from the fact that most threads in multithreaded programs spend most of the time waiting for something to happen. It means that thread entry functions contain endless loops which calls real working functions. By using the ThreadPool type object preparing working functions is simpler and for bonus we get better resource usage. There are two important facts relating to ThreadPool object. There is only one ThreadPool type object per process There is only one working thread per thread pool object The most useful use of a ThreadPool object is to add a new thread with a triggering event to the thread pool. i.e.. "when this event happens do this". For using ThreadPool this way you must perform following steps: Create event Create a delegate of type WaitOrTimerCallback Create an object which will carry status information to the delegate. Add all to thread pool Set event

Read More

what is a thread? A thread (or "thread of execution") is a sort of context in which code is running. Any one thread follows program flow for wherever it is in the code, in the obvious way. Before multi-threading, effectively there was always one thread running for each process in an operating system (and in many systems, there was only one process running anyway). If you think of processes running in parallel in an operating system (e.g. a browser downloading a file and a word processor allowing you to type, both "at the same time"), then apply the same kind of thinking within a single process, that's a reasonable way to visualise threading.

Multi-threading can occur in a "real" sense, in that a multi-processor box may have more than one processor executing instructions for a particular process at a time, or it may be effectively "simulated" by multiple threads executing in sequence: first some code for thread 1 is executed, then some code for thread 2, then back to thread 1 etc. In this situation, if both thread 1 and thread 2 are "compute bound" (all they're doing is computation, without waiting for any input from the network, or file system, or user etc) then that won't actually speed things up at all - in fact, it'll slow things down as the operating system has to switch between threads, and the memory cache probably won't be as effective. However, much of today's computing involves waiting for something to happen, and during that time the processor can be doing something else. Intel's "Hyper-Threading" technology which is on some of its more recent chips (bearing in mind that this article was written in early 2004!) is a sort of hybrid between this "real" and "simulated" threading - for more information, see http://www.yoda.arachsys.com/csharp/threads/