Re: threads

[larz@world.std.com (Mike A Larson) writes:]

>Before too much effort is put into threads, we should consider whether
>existing mechanisms could be modified to handle (much of) the
>functionality provided by threads. Specifically, I'm thinking about
>something like the Plan 9 rfork primitive.

I pondered this, but came to realize that generality does not beget
simplicity. My favorite example is select(), an OS primitive which those of
us in the real-time and/or multiprocessor operating system development and
maintenance world have come to dread. Try making it (1) SMP safe, (2)
preemptible, (3) fast, and (4) scalable all at the same time. And yet it is
the most common mechanism used by servers in a socket environment. It is
not entirely an accident that a VSTa server's msg_receive() accesses a
single port which multiplexes its clients.

In the case of VSTa, there are code paths which are substantially simplified
by the knowledge that they are only accessible from the context of the last
thread of execution under a process. The more variations you permit, the
more general, larger, and harder to maintain your code becomes. Of course,
some of the kernel features in Plan9 have been moved up into the C library
(mount tables) or out to a user mode server (environment variables).
Sharing becomes a user mode policy, not a system one.

This leaves Plan9 options concerning:
        - Maintaining the wait() connection with your parent
        - Process signal (event) group
        - Open file (connection) table
        - Address space

Of these, a VSTa thread does not interact with wait() (although
the process containing it will when the last thread exit()s). Threads
or processes may receive events (if process, each thread receives it).
All threads interact with the single open connection table, and
all threads share the same virtual address space.

So far, VSTa threads have worked out pretty well in practice in my
drivers and in Nick's windowing system. The biggest hole, discussed
today, is that VSTa needs to, but does not yet, offer a mutual
exclusion service to allow threads to efficiently interact.

                                                Andy
Received on Fri Feb 25 20:52:20 1994