new@udel.EDU (Darren New) (05/16/89)
In article <207@doctor.Tymnet.COM> jms@doctor.Tymnet.COM (Joe Smith) writes: >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 You can just boost the priority of your task temporarily. Using Forbid() is needed if any task could screw you up, like while you are walking the free memory lists (since any task could AllocMem and change pointer out from under you). If you only wish to keep a particular task from running while you are, push your pripority up or even better push the priority of the other task down. -- Darren
limonce@pilot.njin.net (Tom Limoncelli) (05/17/89)
In article <15582@louie.udel.EDU> new@udel.EDU (Darren New) writes: > You can just boost the priority of your task temporarily. > Using Forbid() is needed if any task could screw you up, like while > you are walking the free memory lists (since any task could AllocMem > and change pointer out from under you). If you only wish to > keep a particular task from running while you are, push your > pripority up or even better push the priority of the other task > down. -- Darren Let me guess, you haven't taken any courses in operating systems yet; have you? Can you say "unreliable methods of insuring serialization?" :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) Why do I feel like this is a good time for a kroan? I think it's time for someone to write up a big article with tons of sample code about using semaphores so that everyone can start using them with ease. I would also like to see a version of AmigaDOS come out that has semaphores all over the place to make Forbid() obsolete; and in fact C-A could then tell developers that Forbid() and Permit() will not exist in the next release and they have until then to stop using them. Sort of like the VAX VMS manual "Obsolete features" which explains all the system calls that DEC wants to remove but is giving programmers warning. (oh yeeeaaah, someone encourageing C-A to be more like DEC :-) -Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University
new@udel.EDU (Darren New) (05/18/89)
In article <May.16.15.38.59.1989.9730@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >In article <15582@louie.udel.EDU> new@udel.EDU (Darren New) writes: >> If you only wish to >> keep a particular task from running while you are, push your >> pripority up or even better push the priority of the other task >> down. -- Darren > >Let me guess, you haven't taken any courses in operating systems yet; >have you? Can you say "unreliable methods of insuring serialization?" > :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) Actually, I know quite alot about OS's. My statement does stand; if you want to keep another task from running WHILE YOU ARE RUNNING, priorities will work. Note that Forbid() does not disable other tasks from running while you are blocked any more that priorities do. The original statement was along the lines of "I have exactly two tasks accessing common memory and Forbid() works for me" followed by "Avoid Forbid(), use semaphores". I was simply presenting another method. Notice that I have preserved your smiley's, indicating that I recognise your intent and just want to clarify the situations in which prio's are workable. -- Darren
hutch@celerity.uucp (Jim Hutchison) (07/12/89)
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 */