Thread programming I Saturday, October 20 2007
Now a day’s multi processors machines are becoming common and in couple years there might be end of Moore's law (?). so understanding of concurrency is an important thing for any developer. I would like to start from asking what is multi threading? In simple terms, A process (running program) having "multiple threads" means that the process has multiple points of execution. Threads sometime referred as lightweight process, because the creation, destruction and synchronization are cheap when compared with process. A machine with n processing units (n core) can run up to n threads or more in parallel, but in single Processing unit it may give the appearance of running n threads simultaneously by sharing the CPU time by using scheduling algorithm (ex: FIFO/Round Robin).
One of the fundamental question that comes to everyone's mind is when or what situation we should use threads? In other words what are the benefits to end user?
1) When we want the End user to keep busy or avoid long waiting time (responsiveness/throughput)
2) when application performance is an important factor.
Technically speaking,
* context switching between thread is cheap (vs process)
* we have slow devices all around the processor!
* humans are slow (especially feeding input)
* server system has to respond millions of users in a typical web system, a typical pattern is a listening thread to watch incoming requests and worker threads for each user.
* Modern Processors - if we want our program to run faster, the days of buying faster hardware are coming to an end. A single processor can only execute only one thing at a time. Multiple processors, on the other hand, can do multiple things in parallel. Hence can run multiple threads at the same time, Dual-core systems have become very common today, and if we buy a new system, it is somewhat likely that it is dual-core (2 or more processors on a single chip.)
* Response time in Connected systems: practically speaking all modern systems are connected, They access data from other systems (ex: SQL Server, web service, web page etc), Hence the client system has to wait.
Where would we create threads in typical application?
When we need data from out of the box, or when we need data from slow devices within the system (ex: Disk), for high responsive systems we could even introduce thread to avoid latency of lengthy method (ie: the total time between method call and return). so that we could keep the processor busy. Of course there is a trade-off that too many threads may introduce slow execution of the whole program. We could even use Thread pool to further improve the responsiveness by loading ready-made threads while process starts.
Implementation: We have lot options from low level to very modular approaches. At low level (Assembly language) raw thread model gives maximum performance and flexibility with high cost in terms of debugging, maintenance, and implementation time, this approach very suitable for real-time/simulation systems. For typical business applications, our favorite choice would be high-level interfaces with Thread management built in within run time (.net/java etc). So choosing framework/API to implement thread depends on which one saves developer time on implementation, debugging, tuning. Threads are implemented differently in each approach, for ex in .NET
Thread is represented by Thread class. and CLR has built in thread management.
A thread can only belong to a single process.
A thread can belong to more than one AppDomain within a Process
.NET thread does not necessarily map to a physical OS thread
All .NET applications need at least one additional thread for GC. May be more for each additional task (ex: debugging)
Careful designing: Threads behave wrongly if it is not designed in proper ways! - corrupt program state, program hangs, unexpected behavior, program bugs may be difficult to reproduce, As a result multi thread programming requires higher discipline/protocol to handle shared/global memory. At the same time there is a clear need for Analysis of concurrent execution, For example, the problem space is decomposed into sub problems recursively until we get simpler sub-problems, this approach is called functional decomposition. And each sub problems are implemented as methods. Hence functional decomposition defines what needs to be done
Few of the Design patterns which could be used with threads are...
- Boss/Worker model: Boss thread gets tasks and dispatches to worker threads.
- Work Crew Model: Similar to Boss/Worker model, but it has thread pool, where Each thread performs unique tasks, once the pool created then the Boss becomes peer to other threads.
- Pipeline Model: Each thread performs some work and pass the remaining work and result to next thread
Up-Call Model: Layer approach like protocol stack, each layer have thread pool, each layer expect calls from below one.
Versioning: Shared data is versioned and used among threads (Ex Shared Data Set)
The future of Multi thread applications development would abstract further by Drag-Drop, Slide the timing etc on the form like surface and be able to map, schedule etc, and hiding all the internals
