Re: Processes vs Threads

andrew_at_gmvt4.concordia.ca (Andrew Francis) writes:

>In article <784051057snz_at_sambusys.demon.co.uk> psb_at_sambusys.demon.co.uk writes:
 

>In article <3984pm$1es_at_mail.fwi.uva.nl>
>casper_at_fwi.uva.nl "Casper H.S. Dik" writes:
 

>PB>What locking can threads do than is cheaper than semaphores used by
>PB>co-operating Unix processes?
 

> Unix System V style semaphores are expensive since atomicity is ensured
>by storing semaphores and manipulating them in the kernel. Since the Unix
>kernel cannot be interrupted, this is safe. However this makes semaphores
>costly. Also, Unix semaphores are very awkward and difficult to use. Since
>I believe most thread packages try to avoid making system calls, they will
>be faster. I expect them to be considerable faster.

Hello, all. I've truly enjoyed monitoring this thread, but I must now add my own few cent's worth...

The kernel is only non-interruptible on single-processor systems. Other mechanisms are required when multiple-processor systems are involved (this has been the subject of much research, involving, variously, message-passing, or shared-memory mechanisms (with bakery-type cooperative scheduling), among others). The point is, it actually becomes more difficult to allow the kernel to just go merrily on its way, doing what it pleases...

This does not invalidate your point, however. Thread-synchronization is <almost> always less expensive than process-synchronization, often for the simple reason that the entities being synchronized are not global entities, but very localized. Global synchronization will always involve the kernel, whereas local (or 'intra-process', if you will ;-) synchronization often requires no kernel intervention. The above statements hold true especially for user-level threads implementations.

I, myself, don't see the point in duplicating a (possibly) large area of memory, setting up new u-areas, consuming extra process slots, etc, just to be able to perform a subtask within a larger application. The only problems I have with threads, in general, are with the sometimes mindnumbing  complexity (sigh) and the lack of protection mechanisms (outside of those which are under the control of the programmer); as several have pointed out, either of these are horrible, and I shan't belabor the point.

Philosophical note: again, history repeats itself. Operating systems went through many phases before becoming the 'mature' (please don't flame me for this :) systems of today. Some years ago, I can think of another technology that was shamelessly cursed for its character-based interface, its lack of reliability, its *unproven track record*, etc --- anyone know where I'm going with this? (Hint: how could the internet ever have come into existence, without it?) Thus, I submit that only when a technology is stable shall developers be drawn to its use, and, even more importantly, its refinement.

I believe threads, as they stand today, are also in *their* infancy, and so perhaps should not be judged in the context of rather dated artifacts such as process duplication, which perhaps have been optimized to 'work rather well', though the actual design may have been flawed.

Regards,

-- 

William G. Hudacek                      Internet: whudace_at_dad.bgsu.edu
University Computer Services            Bowling Green State University