Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Question about ReleaseSemaphore()
Keywords: ReleaseSemaphore
Message-ID: <4955@amiga.UUCP>
Date: 30 Nov 89 22:38:12 GMT
References: <3156@hub.UUCP>
Reply-To: jimm@batgirl.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 66

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.

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.

)So, my question is: 
)
)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.

)The semaphore structure
)has a field for the owner of the semaphore; would changing this field 
)prior to the release be necessary or desirable? 

Sounds most unwise.  Perhaps it would no longer work in V1.4 when
ObtainSemaphoreShared() does its stuff, since the concept of
"owner" needs to be extended, to -1 or something.

-----------

By the way, there's a standard little puzzle with shared/exclusive
locks which is more convenient to hear from someone than to learn
by experience:  When a shared guy holds the lock, and an exclusive
guy is waiting, what do you do when another shared guy bids for
the semaphore?  

A) Let him past the exclusive guy and share the lock with the
  current guy.

B) Make him wait for the exclusive guy who was there first, after all.

If A), then  the exclusive guy could conceivably never get any
time with the semaphore.  It's tempting to reject this one, but
don't.

If B), then the presence of a queued exclusive guy voids the concept
of sharing between the guys who want to share.  Perhaps there are
situations where this is OK, maybe if you only wanted shared access
for a performance reason.

But if you are sharing semaphores to avoid deadlocks (two tasks
grabbing two semaphores in an arbitrary order works only if the
semaphores (one of them, anyway) is truly shared) B) will not work.

You shall be hanged by the bits until you are dead.

	jimm

-- 
--------------------------------------------------	- opinions by me
"This voice console is a *must*.  I press Execute. 
 `Hello, I know that you've been feeling tired.
  I bring you love and deeper understanding.' "		-lyrics by Kate Bush