Re: threads

[Andrew Valencia <vandys@cisco.com> writes]
> I pondered this, but came to realize that generality does not beget
> simplicity. ... [good reasons why it is better not make existing
> interfaces all things to all people]

Let me rephrase my question in a different way. Assume for a momemt
that a) process context switch time is very fast under VSTA, b) there
is a mechanism for sharing resources, in particular for sharing memory
between processes (a useful thing anyway). Then my question is: given
a) and b) above, does a thread package buy you anything? And if it
does, is it worth the additional effort/code?

[Werner Vogels <werner@ra.inesc.pt> writes]
> My view: I would want threads even in the case where we would have
> rfork(), (you emulate threads on it or whatever.) and rfork would be
> as efficient as promised. I use threads for a number of reasons: (1) they
> allow me to think in parrallel execution of my code in a very simple
> way (2) It easier for me to develop a system that allows 200.000 threads
> sharing an address space than 200.000 processes leaning on the mmu for
> protection sharing (3) non-realtime threads scheduling can be done in a
> simple user-level package that can give the developer of the application
> full control the way he wants his parralel tasks to be scheduled given
> the timeslice he gets from the OS, (4) building synchronization methods
> for threads are cheaper than for full processes for the same reason as (3).

(1) agreed. But, as you mention, it may be possible to emulate a
threads library using existing process-level interfaces (does anyone
know how QNX supports POSIX threads?)

(2) OK, here's an example where a threads are better than processes.
But I wonder if it is common to need so many threads/processes. Two
applications that I have worked on recently, for example, use in the
order of 5 - 10 processes.

(3) this is true for a user-level threads library. Is it true for
a kernel-supported threads environment?

(4) from an implementation standpoint or execution standpoint? If
the answer is implementation, this leads me to an important question:
will VSTa ever support process level synchronization primitives?
If so, then aren't threads-specific synchronization primitives
redundant?

Both Andy and Werner point out that threads are useful. I'm sure that
this is true. But I think its useful to ask the following question: can
we support a reasonable variety of applications with a minimum amount of
redundancy?

                                        Mike Larson
                                        larz@world.std.com
Received on Sun Feb 27 07:03:50 1994