There has been a shift in the responsibility for delivering faster performing applications. In the past, chip makers have been delivering increases in the clock speed of processors. By doing nothing, ISVs got a performance increase since the CPU executed the same instructions in a shorter amount of time. Now, the number of cores is increasing with clock speeds staying relatively fixed. To keep gaining performance on multi-core processors, it is now up to an ISV to parallelize their applications.
Dave Stewart reminds us of this shift in "Don't Thread! The End of the Free Ride." The first part of his title intrigued me. How could software developers expect to gain performance in the future if they didn't thread their codes? Dave proposes the resumption of a tried and true technology to take advantage of multi-core processors. Specifically, using multiple processes instead of threads, to generate parallel execution.
So, how are processes utilized? Windows uses CreateProcess to start up a process (with a single thread) running the given executable file included in the parameter list. The UNIX fork call starts execution of an exact copy (code, data, heap, etc.) of the process that issued the call. You can terminate processes, wait for processes to exit, and even get an exit code from a process that has completed execution. The memory and other resources held by each process are protected from access by any other process. It's like two kids playing in completely different sandboxes on the same playground. Each has access to the same resources (a big box of sand), but can't interfere with each other.
If the processes are working to solve parts of the same problems, but can't touch each other's memory, how can they cooperate or share data? There are several mechanisms. Dave suggests using pipes. There are also sockets, files, mailslots, and others (depending on the environment you're developing in). There are also inter-process synchronization objects to help coordinate the use of any of these methods. If our sandbox kids need to cooperate, they could string tin cans between the boxes (for verbal exchanges) or get other kids on the playground to carry out a bucket brigade between the boxes (for exchanges of sand or their Tonka trucks).
Which method of programming is best? If you've been reading any of the [http://shareit.intel.com/WikiHome/Articles/111111289] collateral on ISN or in the relevant blogs (like this one), Intel is pushing the use of threads. I've heard that influential people like Tim O'Reilly and Linus Torvalds are not in favor of the use of threads. (I'm not sure if they're proponents of process-based computation or feel threads are too low level. Let's assume it's the former, for now, and we can talk about the latter at another time.) I've received an email from a colleague that notes not everyone within Intel agrees with the push of threads as the solution to this question. He suggests that "there are pockets of heresy floating around the Intel technosphere, which have been silenced by our jihad [for] threading." (Now that's a wicked smart turn of phrase.)
That didn't answer the question, did it? Using processes is fine but it requires a different approach to designing parallel applications. The programmer, using cooperating processes, must incorporate explicit sharing of data that is moved from one process to another. This is something more like distributed, message-passing algorithms (like the sandbox bucket brigades). With threads, the programmer must set up some form of mutual exclusion (the dreaded lock) and coordinate the order of threads (write before read) to communicate data from one to the other. Are there tools to examine separate processes and be able to tell when you need to protect variables (or instigate a communication)? I haven't heard of any.
There's not much I can see that takes advantage of the shared resources in multi-core processors when using separate processes. I'll continue to march along with the threading crusade, until something better comes along with a catchier tune to march to.
The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.