What kinds of things would you want in the GNU OS? (really threads)

[Peter da Silva]

I said, I'd like:

> >	context = create_context(context_template); /* Create a context */
> >	status = destroy_context(context); /* Destroy someone else's ctx */
> >	switch_context(context); /* Transfer control to context */
Also, I think you'd need:
	context = my_context(); /* Who am I */

In article <8325 at boring.cwi.nl>, guido at piring.cwi.nl (Guido van Rossum) writes:
> A threads interface without synchronization primitives would be a farce.

I did mean the context switch would be explicit, not implicit. Thanks
for pointing that out. Anyway the three (now four) routines above are
the main core of the system. They can not be implemented in portable C.
Once you have them, you can implement mutexes, or whatever, in portable
code.

> A non-blocking mutex call (atomically test it and set it if not set)
> is a welcome addition.

Since context-switching is an explicit action, implementing a non-blocking
operation is trivial... you just don't perform a context switch in
the middle of it. Let's look at that...

> [depending on explicit context switches encourages lazy programming]

Probably true, but this interface allows a relatively cheap and easy
implementation. It has proven very useful in Forth in real-time
programming.

Besides, these routines allow you to do more than threads. It gives
you simple coroutines (it *is* basically an implementation of coroutines).
It also allows you to implement threads without putting semaphores all
through the standard I/O library. And you can add routines that make use of
threads to an existing program without breaking it.

A more powerful interface would be better, but it would also require
more than a couple of mutex calls. You'd need to add a scheduler so you
knew what context to go to when you're waiting, and so on. Perhaps a
test-and-set call should be added, but really once you get that far
you're getting more ambitious than I think is necessary for a lot of
tasks.

> But the real problem is that you really want to
> use the same threads paradigm on a true multiprocessor.  Both problems
> are expemplified by the Unix kernel.

What you're saying here is that these threads are not as powerful as you'd
like. But they're cheap. And they can be implemented trivially by vendors.

> Oh, on most hardware, mutexes can be made very cheap (a few
> instructions) in the common case that the mutex is free.

But rewriting the standard I/O library to support pre-emptive threads
is *expensive*. If the vendor is willing to do this, then they could
implement a more powerful set of routines, with a scheduler even.

Perhaps you could define the interface for them?

> I personally believe that you don't need primitives to kill threads or
> to wait for their completion; but this is really becoming a different
> thread of discussion. :-)

You're right. Notice I didn't provide a mechanism to wait for completion.
The only purpose for killing the thread is to free the memory used by that
thread's stack and context.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: peter at ficc.uu.net, +1 713 274 5180. | "The sentence I am now
Personal: peter at sugar.hackercorp.com.   `-_-' |  writing is the sentence
Quote: Have you hugged your wolf today?  'U`  |  you are now reading"