English | 中文 | Русский | Français

2,595 Posts served

8,341 Conversations started

Is DOS the ideal parallel environment - Part I

By Asaf Shelly (16 posts) on August 25, 2008 at 3:55 pm

Previous article described the evolution of computer languages from early days Assembly to Object Oriented languages favored today. The emphasis was that early languages had clear execution flow that could be abused into "spaghetti code" (so many jumps / GoTos in the code that it becomes unmanageable), and on the other hand computer languages evolved to adopt the Object Oriented paradigm which can be abused into "spaghetti flow" (single flow passes so many objects that execution flow is untraceable).

 

These questions are raised only today because until now we had only a single core CPU and we used a few threads very carefully. Today we are facing a revolution that could bring 128 CPU cores very soon. In order to utilize the CPU we must use multiple threads. To fully utilize a 128 core CPU we must use at least 128 threads (worker threads, not waiting threads). The bad news is that most applications do not have 128 different processes at the same time. Usually it is between one to a few CPU consuming processes simultaneously which means that we will end up having multiple threads doing the same job. Using locks is out of the question because a lock is a way to pin down a resource to a single core which is the opposite of using multiple cores.

 

Before we go any further to talk about advanced solutions and new models, we should take a look at existing technologies that are available today. The technology that most affects us is the environments in which out code runs. We must familiarize ourselves with these environments – the operating systems and its services.

 

Going from the most commonly used to the least, I will start with Windows (NT based) OS. It is important to mention that the Windows OS is made out of two completely different operating systems. One is User Mode With its Win32 API and the other is Kernel Mode that has a completely different programming model, API, and execution environment. We start with Windows User Mode, then UNIX, continue to Windows Kernel, and last explore DOS as an ideal parallel system.

This article is broken into four parts because of it's length.

 

 

Windows User Mode

Originally User Mode Windows started as an expansion of DOS. Later this operating system was ported over the Windows NT Kernel instead. The Windows OS was based on graphical windows and each window is owned by a thread. This is a very good design because instead of sharing ownership over the resource (window) only a single owner exists, thus no need for locks.

Windows OS uses messages to initiate operations on a window, so each window responds to a predefined set of operations such as 'mouse move', 'window resize', and 'plug & play events'. We can say that the window supports predefined sets of operations and the system can initiate these operations. In other words every window supports a predefined set of Tasks. When we want our window to support new types of tasks, other than the predefined, we register the new type of Task with the system or we silently define it internally between our windows.

 

The concept of events sent to an object is very good. The implementation defined a huge switch-case that detects the type of event (or Task) sent and made it almost impossible to manage the code. Then came along MFC which was supposedly an Object Oriented wrapper. This was bad in so many ways. First of all Object Oriented code only works if the design was Object Oriented. MFC tried to wrap the flat design. On the other hand MFC now hid the huge 'switch-case' implementation and made it even harder to add event handlers on the fly. Eventually the event-driven model of windows was almost forgotten.

 

User Mode Windows had all these window messages sent through a queue. The queue belongs to the thread that owned the window. This model is very good and still exists. Every thread has a message queue and every thread can post messages to a queue that belongs to another thread or to its own queue. Using message queue communication means that threads do not share resources and thus no locks are used. No locks means no deadlocks, no race conditions, and means an increase in overall system performance (because a lock is a way to pin a resource down to a single core). This is a very good model that was also long forgotten and most times when a queue is required developers use Message-Queues engines, databases, or network sockets. The model is very good but the implementation was somewhat problematic, having some very limited queue length, API that uses the windows messages format, and almost no marshaling support which means that allot of work is required for a very simple operation.

 

Windows User Mode uses processes and threads. Every DLL loaded to the process receives a callback when the process is created and when it exits. Also every dll is called for every thread created and every thread closed. This allows implementations of extremely good technologies such as TLS (see this link: http://AsyncOp.com/Link.aspx?TLS ). However most developers do not really know TLS even though it exists for over 10 years, they do however know how to create a thread and the intuition says that when you want a task performed you create a thread and when you want it closed you close that thread. On the Window User Mode OS this means calling all the initialization callbacks in all the DLLs attached to the process. So here again we have an exceptionally good mechanism that almost nobody is using and instead we get bad code implementations. UNIX can live with multiple processes and threads created and destroyed. Under Windows User Mode OS if the actual work to do is about 10 lines of code long, then creating a thread and closing it should multiply work that would slow the process approximately 100 times in relation to a process that recycles threads (thread-pool).

 

 

 

Next part of this article analyses the built it in parallelism of the UNIX OS.

 

 

 

 

Categories: Parallel Programming

Comments (8)

Trackbacks (1)

• Intel Software Network Blogs » Is DOS the ideal parallel environment - Part II
  September 2, 2008 5:47 PM PDT

Leave a comment  

Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*