I just got semaphores working at the user level!
They are FIFO, and for now if the resource is not available,
the requesting thread simply drops into the kernel
(as opposed to spinning). I think that's the right thing
to do for uniprocessors, but the code will soon have a
per-semaphore spin count which will default to zero,
but which the intrepid hacker may modify by function call.
To the user a semaphore is just an integer returned by a
call to tsema_new(). The functions tsema_wait() and
tsema_signal() and tsema_free() all take that integer
as argument. Threads are blocked until the requested
resource is available. It should even work in out-of-
memory situations, if one pays close attention to the return
values!
The semaphores are a bit of library code plus two system
calls, recently renamed to tsleep(lock_t*) and twake(pid_t).
If the lock_t pointer to tsleep is passed in null then
it's a generic routine to put a thread to sleep. twake()
will wake up any thread which is in the same address space
as the calling thread.
There's also a user-level spinlock, using the lock_t type, and
I need some advice there. Ideally the assembly code that
calls the test-and-set operation should simply return the
result of that test, but I don't know how to pass a return
value back so that C knows what I'm doing. Anyone want to
enlighten me? Right now the assembly code spins until it
gets the lock, but I want to put in a counter, and it seems
silly to code it in assembly... easy enough, but silly.
The last bit of work is the tricky stuff; I need to get
the interrupt and event handling right in the tsleep(lock_t*)
system call (which is a ripoff of p_sema). I'll probably
be doing that in personal e-mail, unless folks really want
to hear about this...
Gary
Received on Sun Nov 27 17:24:49 1994
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:10 PDT