I don't have access to any OS other than Win32 currently.

I could produce examples written in C for this platform that demonstrate that thoughput can be increased (on this platform) using a 3-thread process over a single threaded process, despite the OS providing considerable cacheing. However, as I cannot match that with a fork and IPC example, there is little point.

I was party to some comparisons done using AIX showing that threading could outperform seperate processes with shared memory buffers and system semaphores. The nature of the task described, 3-threads, 2 buffers, each buffer written by one thread and readonly to a second is probably the strongest example, by reason of it's simplicity, for the threaded model.

However, there are many variations where input from one or more external sources is subject to wait states, and the data needs to be centrally processed, where threading has an advantage over the forked model.

There are, of course, many counter examples where forking is hands down winner on OS's where forking is a system level facility. And that's the bottom line. If the OS supports one natively, that will be the best option over any user space implementation of the other.

Where an OS supports both, using threads where IPC is required will usually win over shared process memory because it is possible to use much lighter semaphore implementations. Where there is no requirement, or only trivial volumes, of IPC required, and the OS has many years of development into making forking fast and efficient, the forking model will prevail.

Then the waters muddy further when you start considering non-native threads. Personally, I don't think it makes a great deal of sense to implement threading at the application level, ie. outside or alongside the OS schedulers control, as with the java threading. The result is a mish-mash that sees two disparet systems interacting to control the scheduling. The results of that interaction are extremely difficult to predict or manage.