Re: Processes vs Threads

Okay, I used to work at Transarc, and I worked on MACH at CMU. The logic behind threads is very clear, although some people seem to be missing the point.

First, threads exist in order to minimize synchronization costs between parallel units of execution. In standard Unix, fork can be used to get a "parallel" execution unit, but transferring data between these programs can be expensive. One of the cheapest ways is shared memory, but this requires the programmer to carefully manage that memory, and it become a real pain as you scale up on the number of execution units (programs). Other options in traditional unix systems have been semaphores or file locks.

All of the traditional synchronization and data transfer methods become even more expensive when you have process level context swaps occuring in the kernel.

In order to get around this problem, the MACH people in parallel with other research orgs around the world, experimented with Threads. With threads, you go back to the good/bad old days of a single memory space for all execution threads. The positive is that you have very cheap synchronization and data communication between execution units. The drawback is that your code had better be correct, otherwise one thread can kill the others.

Initially, threads ran within a single kernel process. These were called co-routine implementation, and they provided cheap relatively portable threads. The drawback is that you did not get multi-processor support.

MACH added true kernel threads, and then these threads started to run on multiple processor with true parallelism. We found that as while true threads are cheaper than processes, its not that much cheaper. Thus one of the original arguments for threads (that processes had to large of a kernel overhead) when away.

These days, we have the best of both worlds. Solaris2 has a hybrid threads implementation. Real cheap co-routine threads, connected to more expensive true kernel threads. I've seen reports of programs with hundreds of threads running very smoothly (and quickly) on such systems. These threads even migrate between processors.

I don't believe that threads are for everyone. The big drawback is the single memory model, but its also its biggest benefit. Transarc and the OSF based there systems on threads because the number of parallel execution units and the synchronization overhead would have swamped a tradition process implementation. A simple Encina program might have as many as 15 threads, most of them dormant until some particular event occurs.

Just to be clear, threads were not invented by MACH (and CMU). The database vendors have been using co-routine implementations internally for many years. What MACH and its likes did was standardize a threads interface which could hide the underlying threading implementation.

Enjoy,
Elliot jaffe
Applicom System Ltd. Received on Thu Nov 17 1994 - 06:57:36 CET