Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!oliveb!amiga!boing!dale
From: dale@boing.UUCP (Dale Luck)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 1.4 Wishes
Message-ID: <699@boing.UUCP>
Date: 7 Apr 89 22:14:26 GMT
References: <8904041835.AA01760@jade.berkeley.edu>
Reply-To: dale@boing.UUCP (Dale Luck)
Organization: Boing, Milpitas, Ca.
Lines: 30

In article <8904041835.AA01760@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:
>Well, since everybody is twisting their tongues at full speed spelling out
>their 1.4 wishes, I guess I should too. (There is nothing wrong following the
>herd of sheep, is there?)
>
>
>3. Use semaphores to enforce mutual exclusion. Currently the Sassenrath way
>   of implementing mutual exclusion is to use the Forbid()/Permit() functions.
>   Theoretically, on multi-processor machines we have to use RMC (Read-Modify-
>   Write) cycle instructions, since this is the only way we can insure that no
>   other processor will modify a semaphore at the same time. Theoretically, on
>   single processor machines all we have to do is disable multitasking, thus
>   we insure that no other task will modify a semaphore simoultaneously.
>

I agree, Forbid/Permit is a nasty way to protect long (time) critical regions.
The Sempahores are much more elegant, even though they themeselves use
Forbid/Permit for their critical regions of incrementing/decrementing
counters. But these are very small and usually only a couple of machine
instructions.

The Semaphores were first implemented by graphics to provide exclusive
access to layers. It was agreed that this function was better handled by
exec so the code migrated from graphics.library to exec.library before
final release.

It is time that the rest of the system make use of these functions.
-- 
Dale Luck     GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dale