threads (was Re: [gclist] Re: gclist-digest V3 #84)

[Scott Meyer]

At 10:06 PM 6/22/00 -0700, Bob Kerns wrote:
>
>
>-----Original Message-----
>From: Andrew Chen [mailto:chenandr@cse.msu.edu]
>Sent: Thursday, June 22, 2000 20:42
>To: gclist@iecc.com
>Subject: %%: threads (was Re: [gclist] Re: gclist-digest V3 #84)
>
>>Unix supports shared memory between two processes, and this is 
>>precisely what threads are, only a different amount of memory is 
>>shared. Yet processes are considered heavy and threads considered 
>>light in Unix and Unix derivatives. Why is this?
>
>Even when two processes share all the same data, at the same addresses, they
>are not sharing the address space. You can easily see this, because you can
>make a change in one process (e.g. loading a shared library, or creating a
>page somewhere deep in malloc, etc.), and it will not be reflected in the
>other.
>
>There are a lot of data structures in Unix that are per-process. As you
>would expect from the previous paragraph, one of them is the map from
>addresses to actual physical pages. Assume for a moment that page maps have
>to be stored in non-paged memory, and take up 8 bytes per physical page of
>4096 bytes. This would be 8 Mb RAM, for a fully-populated address space.
>Now, perhaps the page table will be paged, or less space used via various
>compression tricks, but even so, that's up to 8Mb of data ON TOP OF the
>overhead per thread (remember, each process also uses at least one thread).
>
>Different systems may vary as to the cost, but I think it's plain that,
>compared to a thread, a process is an inherently "heavyweight" construct.

The Point to which I was perhaps too obliquely alluding is that
programmers have (repeatedly) "invented" process-like things and,
in point of fact, use them to accomplish a very large proportion
of the "real" (ie. non-programmers actually pay money to have it
occur) computation that takes place in the world.  This pattern
suggests that there is some value to this notion of process that
makes the "extra weight" worth carrying.  Comparing a thread
to a process and claiming the former to be "lightweight" is
akin to comparing a chassis to a complete car.  Of course the
chassis is lighter...  You need to compare complete applications.
For example, if you have to handle input on 100 sockets is it
more heavyweight to fork 100 threads and let them block in read,
or to have one process blocked in poll?  Like most things IRL,
not quite so clear-cut.

Speaking of actual implementations of threads and processes,
there is some difference (page tables, acls, etc.) between the
two, such that threads appear to be somewhat cheaper than
processes.  Unfortunately, (for thread-partisans) the nominally
cheaper threaded environment comes at the cost of a heavy
burden of heretofor "system-level" mutual-exclusion issues.
The naive approach to resolving these issues, making all libraries
thread-safe, has a disasterous synchronization overhead and
is very difficult to debug.  Most recently, this issue seems to have
motivated the Java architects to rediscover the idea (previously
rediscovered by the Smalltalk crowd) of leaving most libraries
unsynchronized and providing a small set of synchronized data
structures.  Or at least trying to.

In my experience, most successful uses of threads come very
close to that model or to the purely functional varient
suggested earlier in this discussion.   In practice it is
pretty hard to measure much difference between this stylized
use of threads and processes with shared memory.  Pragmatically,
it is a hell of a lot easier to implement the process version
of things.

-Scott
Scott Meyer                                   415 506 0987
Principal Member of Technical Staff
mailto:smeyer@us.oracle.com
Oracle - Languages & Relational Technology    standard disclaimer