Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!lll-winken!uunet!seismo!esosun!cogen!celerity!celit!hutch From: hutch@celerity.uucp (Jim Hutchison) Newsgroups: comp.sys.amiga.tech Subject: Forbid()/Permit() (was Re: unloadseg()) Message-ID: <366@celit.UUCP> Date: 12 Jul 89 01:21:20 GMT References: <1367@inria.inria.fr> Sender: news@celerity Reply-To: ucsd!celerity!hutch (Jim Hutchison) Organization: FPS Computing Lines: 52 In article <1367@inria.inria.fr> rouaix@inria.inria.fr (Francois Rouaix) writes: >Forbid() and Permit() work by incrementing and decrementing a counter >(TDNestCount (sp?)) which tells the scheduler if the task may be switched >or not. Now if you write too much Permit() (ie more than Forbid()) in the >code, then the value in the counter might get negative. A later Forbid() will >then have NO effect. [...] >Since this was so much pain to debug, I'll make a wish for 1.4 ! >I want that Permit() checks the counter so that it can never get >negative (one MOVE is enough...). >(Note how it is similar to some Lisps that allow superfluous closing >parenthesis) There is a problem with this, how is '1.4' going to know when Permit()s should start permitting again, if the value didn't change? The increment decrement is a way to make sure that nesting is safe. How about something similar to: flag = Forbid(); ... Permit(flag); When you call it, you get the current state, and when you restore it you put back the previous state. This is much like spl()'s in the Unix kernel. For the moment you could make a library call to do the same thing. Not that 'Forbid()' is a resource that only 1 process can hold at a time, by definition. int hog_processor() { static char forbidden = 0; Forbid(); /* set forbid, protect 'forbidden' */ if (forbidden) { Permit(); /* 1 Forbid() is enough */ return(1); /* state was true, forbid */ } else forbidden = 1; /* Forbid() active */ return(0); /* state was false */ } } unhog_processor(val) /* re-entrant :-) */ int val; { if (val) return; Permit(); } /* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */ /* Disclaimor: I am not an official spokesman for FPS computing */