Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.wizards Subject: Re: What kinds of things would you want in the GNU OS? (really threads) Message-ID: <5623@ficc.uu.net> Date: 9 Aug 89 19:58:53 GMT References: <160@uucs1.UUCP> <8311@boring.cwi.nl> <5568@ficc.uu.net> <8325@boring.cwi.nl> Organization: Xenix Support, FICC Lines: 71 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@boring.cwi.nl>, guido@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@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"