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

[Fergus Henderson]

On 26-Jun-2000, Hans Boehm <hans_boehm@hp.com> wrote:
> 
> 4) It's usually a mistake to use processes when you need to share lots of
> state, though databases may well be an exception to that rule.  Aside from
> performance issues, using processes means that there's no guarantee that
> that pointers point to the same thing in all participating processes.  This
> is not an intuitive model.
[...]
> 5) Until fairly recently, you couldn't use threads in portable code, and
> expect them to take advantage of multiprocessors correctly.  You could do so
> by building on processes.  I think this has finally changed, but it probably
> explains a lot of the processes-with-shared-memory implementations. 

My experience agrees with that.  When we first started implementing a
version of the Mercury compiler that supported parallelism, our first
attempt used multiple processes with shared memory, in order to take
advantage of multiprocessors.  But we found this quite difficult.
One reason for this was that there was no portable support for dynamic
memory allocation using shared memory, so we had to build that
ourselves, by adapting one of the free malloc() implementations.
Even then there would still have been problems with e.g. putting `FILE *'
pointers in shared memory, since there's no way to tell fopen() to
allocate the memory using a different allocator.

At some point threads became sufficiently portable that we could
switch to using them instead, and when we made that switch, things
became a lot easier.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.