TEETER%HUMBER.BITNET@cornellc.cit.cornell.edu (Doug Teeter) (05/01/89)
I know this question has likely been asked and answered a few thousand times
but if someone in the know would give me the answer, I would be truly grateful.
Under what conditions are they required and which one should be used when?
ie. when adding IText or Border structures to an active gadget?
when changing the ImageData pointer of an image?
when fiddling with Window Flag bits?
Oh ya! Is it okay to use the ExtData(sp?)(just before the UserData) of the
Window structure form my own purposes?
Thanx in advance for any response to these lame questions.
....Teeterewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/02/89)
In article <14333@louie.udel.EDU> TEETER%HUMBER.BITNET@cornellc.cit.cornell.edu (Doug Teeter) writes: > Under what conditions are they required and which one should be used when? > > ie. when adding IText or Border structures to an active gadget? RemoveGadget (foo, bar, grill, etc, etc, etc, ....); MuckWithGadgetGraphics (); AddGadget (even, more, inconsistent, parameters, ....); RefreshGadget (still, more, shades, of, stdio, parameter, ordering); [ I've been kvetching lately about how none of the Intuition gadget manipulation function parameters are consistent, which makes it hard for me to remember what they are. ] > when changing the ImageData pointer of an image? You can pretty much do this any time you want with impunity. There is a small chance of a collision, but if you lay things out right, you should be able to avoid them. If you are the only one who will be rendering the Image, you *can* modify the ImageData pointer at any time. > when fiddling with Window Flag bits? > Forbid (); FiddleWindowFlags (); /* Please be quick here. */ Permit (); > Oh ya! Is it okay to use the ExtData(sp?)(just before the UserData) of the >Window structure form my own purposes? > Probably not. However, JimM is God on this one. JimM? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jms@doctor.Tymnet.COM (Joe Smith) (05/16/89)
In article <9160@polya.Stanford.EDU> gilham@polya.Stanford.EDU (Fred Gilham) writes: >I used Forbid() and Permit() to allow me to start up a task where >things weren't quite ready for it. The parent simply did a Forbid() >until it had finished setting things up. This seemed like a good use >of Forbid() to me. Most of the time, a program using Forbid really doesn't need to stop all scheduling. That's like using a sledge hammer as a fly swatter. We really need a call that will tell the OS not to schedule one particular task, or class of tasks. I guess that's what others mean when they say we need semaphores instead of Forbid/Permit. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/17/89)
For anybody interested, the more recent distributions of my sup32.lib
and dres.library contain simple, extremely efficient lock and unlock routines:
long Lock[2] = { 0,0 };
LockAddr(Lock);
UnLockAddr(Lock);
8 locks are available pre Lock structure (two longwords initially 0),
where [Un]LockAddr() defaults to bit 0, and two other calls exist to handle
the other 7.
The routines are extemely fast when the lock can be gained and use
the stack to put themselves on an unlock list when the lock cannot be gained
(i.e. when they block). One can bind the lock to, say, a global named port
structure to name it.
The routines are different from semaphores in that they have very
little overhead ... 2 longwords and temporary use of a task's stack if they
block. These are exclusive locks only.
-Mattdeven@rpi.edu (Deven Corzine) (05/18/89)
In article <8905170309.AA23406@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > 8 locks are available pre Lock structure (two longwords >initially 0), where [Un]LockAddr() defaults to bit 0, and two other >calls exist to handle the other 7. BYTE 0, you mean? -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
jimm@amiga.UUCP (Jim Mackraz) (05/19/89)
In article <8905170309.AA23406@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
)LockAddr(Lock);
)UnLockAddr(Lock);
Do they Nest?
Do they call Forbid in UnLock? (PS: Unlock is a nicer spelling ;^)
No vulnerability at all, right?
jimm
--
Jim Mackraz, I and I Computing "He's hidden now, but you can see
{cbmvax,well,oliveb}!amiga!jimm The bubbles where he breathes."
- Shriekback
Opinions are my own. Comments are not to be taken as Commodore official policy.