Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!oliveb!amiga!mitsumi!jimm
From: jimm@mitsumi.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga
Subject: Re: Intuition's "dont mess with these" fields...
Message-ID: <700@mitsumi.UUCP>
Date: Fri, 30-Oct-87 17:30:57 EST
Article-I.D.: mitsumi.700
Posted: Fri Oct 30 17:30:57 1987
Date-Received: Thu, 5-Nov-87 04:03:24 EST
References: <1961@amiga.amiga.UUCP> <1825@cadovax.UUCP> <21469@ucbvax.BERKELEY.EDU> <1830@cadovax.UUCP> <21519@ucbvax.BERKELEY.EDU>
Reply-To: jimm@mitsumi.UUCP (James Mackraz)
Organization: Mitsumi Technology Inc
Lines: 74
Keywords: Intuition lockibase forbid

In article <21519@ucbvax.BERKELEY.EDU> shs@ji.Berkeley.EDU.UUCP (Steve Schoettler) writes:
)In article <1830@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
)>>	key=LockIBase(0L);
)>> [ do protected processing ]
)>>	UnlockIBase(key);
)>
)>Sounds reasonable.  Is this any better/worse/different than doing a
)>Forbid()/Permit() or an Enable()/Disable() ?
)
)  YES!!!
)
)  The main difference is that LockIBase allows other tasks to run
)(except ones that want to LockIBase also).
)	[ other valuable comments ]
)Steve Schoettler

This misses a key point which Bryce's posting got right, but deserves
further emphasis.  Before I go on, let me say that using semaphores
rather than Forbid/Permit is important, and Steve's comments are 100%
correct about that, I think.

Whether Forbid/Permit or ObtainSemaphore/ReleaseSemaphore (which is
LockIBase() amounts to) are used to arbitrate shared data between
multiple tasks, it is generally necessary that all tasks use the
same arbitration method.

In this case, if Intuition says LockIBase() and starts walking down
the list, if you come with a Forbid(), this keeps intuition locked out,
but either a) IntuitionBase may not be in a stable state: linked lists
may be in the process of corruption or b) Intuition will crash when
it regains control because you have invalidated an assumption about
IntuitionBase that is has temporarily made (e.g. removed the node
in a list that Intuition was working on when interrupted).

Now it turns out that most of the time, there won't be a problem, because
Intuition runs at a higher priority than your tasks (normally), so it
tends to run to completion (i.e., past UnlockIBase()) before you can get
in with your Forbid().  But if Intuition waits for the Blitter or other
resource (or for a lock held by yet a third task), Intuition gets blocked,
your task might run, and POOF!

Note that I don't recommend using priority as an arbitration technique
in any case.

Note also that using Forbid/Permit as the arbitration mechanism is what
made Intuitions prior to 1.2 highly unstable.  This is because
waiting for a signal or the blitter (ie calling Wait()) RELEASES the
hold of Forbid(), so a competing task can get in and run.

Lessons:
	Forbid/Permit simply do not arbitrate operations on data if
	the function Wait() may be (even indirectly) called.  Note that
	LOTS of system functions call Wait() one way or another.

	Forbid/Permit don't arbitrate data operations where they might (like
	walking linked lists) unless ALL USERS of the data use Forbid/Permit
	which Intuition does not do.

	Semaphores work good, if everyone uses them.   LockIBase() uses the
	Signal Semaphores, functions including ObtainSemaphore() and 
	ReleaseSemaphore().

	And as Steve stressed, semaphores lock just the data they are
	supposed to, without shutting out other tasks needlessly.
	Learn 'em, use 'em, love 'em.

That lock-a-billy guy,
	jimm


-- 
	Jim Mackraz
	Mitsumi Technology, Inc.		408/980-5422
	{amiga,pyramid}!mitsumi!jimm