🚀 go-pugleaf

In article <4955@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes:
>In article <3156@hub.UUCP> panzer@cornu.ucsb.edu (Panzer) writes:
>)
>)I'm trying to implement a low-overhead shared (read) lock using
>)signal semaphores, and I've come up with a way that will work
>)if several tasks can effectively share ownership of a semaphore.
>
>We have found a way to implement shared-read/exclusive-write style
>semaphores using the existing semaphore structure, where existing
>callers of ObtainSemaphore magically become "exclusive" in this
>extended scheme.


Great!  So when will 1.4 be out? :^)


>I recommend that you write your own obtainexc/obtainshare/release
>routines around an existing signal semaphore structure that is
>not used by anybody making the Exec calls.


I was hoping that I wouldn't have to move down to signals.  It
seems necessary, though. 


>)What happens if a task ReleaseSemaphore()'s a semaphore which another
>)task had previously ObtainSemaphore()'d? 
>
>For one thing, it's not a semaphore anymore if you deny a task the
>opportunity to decide when it's good and ready to release it.


Well, naturally you'd make sure nobody owned the shared semaphore before
it was released to the system.  (A usecount would work.) 


My manuals are unclear about one point:  When allocating a signal bit, 
can I rely on getting whatever bit I want (within the 16 task-reserved
bits, of course)?  Or do system functions or compiler libraries ever 
use these task bits?   

 
==========================================================================
| John Panzer           | University of California, Santa Barbara        |
| panzer@cornu.ucsb.edu |        School of Computer Violence             |  
==========================================================================