Home » Blog » Windows Application, Processes & Threads

Archive for the ‘Uncategorized’ Category
Windows Application, Processes & Threads
Friday, April 16th, 2010

How does Windows allocate CPU time?

CPU (Central Processing Unit) time is incredibly valuable. It determines how much and how fast code can be executed (in the context of length of time in regards to amount). Because of this, the operating system has to be conscious of how it split processing time between the different programs and services that are running. In order to make this a reality, various structures are needed to represents the executing code.

Applications – Processes – Threads

An application consists of one or more processes. A process is an executing program. One or more threads run in the context of the process. A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the process code, including ?parts currently being executed by another thread. All threads in a process share the same memory and system resources. Each CPU core can execute one thread at a time, so multi core systems can execute as many threads in parallel at the same exact time as the amount of CPU cores available.

To recap, a threads make up a process which makes up an application. The simplest application will have one process consisting of one thread. Multi threaded applications can have multiple processes with multiple threads.

Thread Pools

Creating and terminating a thread is very time consuming. Memory allocation, thread management, and processing time are all involved in handling multiple threads. The more threads an application has, the more of these resources it will consume.

Some applications are written to take advantage of multiple threads and run processes (not windows process, but a literal one) in parallel. Some of these processes are very short lived and make the cost of creating and terminating the thread very expensive. In a way, the ROI is not high enough.

In order to make multi threading less expensive resource wise, thread pools were introduced. Thread pools are collections of worker threads that handle processes on behalf of the main thread.

A good analogy to this would be a restaurant. A new waiter (thread) would have to be hired every time a customer walked in the door. The waiter would take the order, bring the food, charge the fee, and do other tasks. When the waiter would be done serving that customer, they would be fired (thread terminated) and a new waiter hired for the next customer. This is incredibly inefficient if there are many customers and they spend very little time in the restaurant. A thread pool would be like having a staff of waiters ready to serve new customers as they walked in.

Process & Thread Priority

The operating system dictates how much processing time is given to each process based on the process priority. In windows, you can change the priority of a running process by using the Windows Task Manager and the processes tab. Similarly, processes can change the priority of the treads that make it up. By assigning a higher priority, that particular thread would get more processing time allocated to it.

A good use of this would be in an application that has heavy background processing. The thread responsible for the UI should have a higher priority then the thread which is running background processes. This would ensure that the application is responsive to the user input.

Memory Sharing

While multiple threads can execute the same exact code at the same time, they can not read and write to the same memory space. Safeguards are built in to ensure that memory access by multiple threads don’t overlap. Race conditions are one of the biggest problems in multi threaded applications. When one thread starts reading or writing to a piece of memory, other threads have to wait for it to finish.

An example problem would be two threads needing to read the same memory. Thread A starts reading some memory, but can’t finish until thread B sends a value back that thread A needs in order to finish its calculation. Thread B, in order to send the value back, needs to read the memory that Thread A has locked. Both threads are now waiting for each other and are in a deadlock.

Thread Timing

Windows splits up processing time between threads based on priority. As each thread gets a given amount of clock cycles to process. If the thread finishes processing before the time is up, it returns the processing time to the OS. The extra time is then added to the pool of time and split among the other threads. If after every thread has processed there is extra time left over, the time is allocated to the System Idle Process that can be seen with Windows Task Manager.

Multi Threading Considerations

Problems such as the deadlock and race conditions described are some of the challenges that face multi thread applications. Taking advantage of powerful systems with multiple cores capable of running multiple threads at once increases processing speed, but developers have a lot more of challenges to work with. The timing or threads, the work they do, and the memory they share are all thrown into the equation when designing multi threaded applications.

HAPPY CODING!

SunSpider Browser Benchmarks
Tuesday, March 23rd, 2010

Web 2.0

If you don’t already know, most of the web 2.0 technologies today are built on top of javascript. Javascript is scripting language that browsers use to perform the more advanced features of a website. All of the pretty CCS layouts, the XML traffic, and of course the constant tweeting and face-booking would not be possible without this language and the support browsers provide for it.

Browsers

As most of us know, different browsers render pages differently, some are more efficient then others at different tasks, and some are more secure. Some of the bigger players come pre installed on the os of your choosing, while others sit quietly behind the scenes and wait for the few followers to download them. In any case, one thing is universal, each and every browser is ultimately different then the other.

Benchmarking

Benchmarking is a way to test the speed and efficiency of a task. Benchmarking javascript, up until recently, was almost impossible. There have been lots of micro benchmarks here and there, but no true test that sums of the speed of the javascript engine in a browser.

WebKit Open Source Project

Webkit.org is the home of the open source web browser engine developer by Apple, currently used in Safari and multiple OS X applications. One of the tools it provides is the SunSpider Javascript Benchmark, a true representation of a browsers javascript performance. By testing multiple facets of a browsers javascript processing speed, we can gain a balanced real world comparison between the different processing speeds different browsers offer.

Chart in milliseconds (Lower means quicker – total was divided by 5 to fit nicely in chart)

SunSpider

Raw Numbers

3D Access Bitops ControlFlow Crypto Date Math Regexp String Total
Internet Explorer 9 Beta 440.6 544.6 489.4 86.6 245 183.2 270.8 39 466.4 2765.4
Internet Explorer 8 668.4 929.6 725.4 139 389.8 474.2 595 208 1012 5141.6
Firefox 3.6 165.4 165.4 51.8 47 65.8 164.4 68.6 56.8 279 1064.2
Safari 4.0 71.8 60 37.4 6.2 40 78.4 61.6 26.2 210.6 592.2
Chrome 4.1 81.6 43.4 48.4 3.4 38.4 67.6 504 18 193.8 545
Opera 10.51 62.2 53 23.2 5.8 30 69 56.6 15.6 153.6 469

Conclusion

As you can see, not all browsers perform at the same speed. Lagging far behind is Microsofts Internet Explorer 8. While IE 9 promises, and in tech previews proves to have made huge leaps in closing the gap behind the other leading browsers, it suffers from slow release cycles. The other leading browsers push routine updates which enables the end user to browse at the fastest speeds available while IE leaves months, or years in between version releases.

The true test of speed is yet to come. As more Twitter and Facebook sites pop up, and web 3.0 inches closer, it is up to the browser developers to ensure they keep up with the new demands for speed and efficiency.