alex@lancelot (04/09/86)
From: Alex Bronstein <alex@lancelot> Hello, Assume I want to busy loop in the kernel for 100 milliseconds, how many times (approx) should I go around a loop which increments an int? (Yes I know you usually don't want to busy loop in the kernel, in fact, I know how to do it the "smart" way, with sleep, and timeout, but for once I really need to busy loop for a short time..) Thanks, Alex
dave@onfcanim.UUCP (Dave Martindale) (04/17/86)
In article <234@Shasta.ARPA> alex@lancelot writes: > > Assume I want to busy loop in the kernel for 100 milliseconds, how >many times (approx) should I go around a loop which increments an int? > Do you *really* want to lock up the processor for that long? sleep/wakeup would make much better use of the processor. But if your really want a busy loop, you realize that this depends on what processor you are running on, which you didn't mention? A Cray-2 and an 8088 can both run UNIX, but there is a fair difference in the number of instructions they execute in 100 ms. Tell you what. Why not write a program like this: main(argc, argv) char **argv; { long i, limit, atol(); limit = atol(argv[1]); for (i = 0; i < limit; i++) ; } Then run it until you find a value of the argument that gives an execution time of 10 seconds. Divide that number by 100, and you will know how many times to go around a loop to get 100 milliseconds pretty accurately. Seriously, wouldn't it have made more sense to just write the test program and have your answer in 3 minutes, rather than posting an article that several thousand people would read, particularly since they can't answer it from the information given? USENET is a wonderful resource for obtaining hard-to-find information. I hate to see its effectiveness damaged by people using it as a crutch. Dave Martindale
chris@umcp-cs.UUCP (Chris Torek) (04/17/86)
In article <234@Shasta.ARPA> alex@lancelot writes: > Assume I want to busy loop in the kernel for 100 milliseconds, how >many times (approx) should I go around a loop which increments an int? In a 4BSD kernel, use the `DELAY' macro. DELAY(n) takes approximately n microseconds to complete: DELAY(100000); /* 100 ms */ The actual delay is *very* approximate. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
campbell@sauron.UUCP (Mark Campbell) (04/18/86)
In article <234@Shasta.ARPA> alex@lancelot writes: >From: Alex Bronstein <alex@lancelot> > > Assume I want to busy loop in the kernel for 100 milliseconds, how >many times (approx) should I go around a loop which increments an int? 42 -- Mark Campbell Phone: (803)-791-6697 E-Mail: !ncsu!ncrcae!sauron!campbell
stevesu@copper.UUCP (04/21/86)
In article <234@Shasta.ARPA> alex@lancelot writes: > > Assume I want to busy loop in the kernel for 100 milliseconds, how >many times (approx) should I go around a loop which increments an int? A fixed-time busy-wait is okay, but everybody should beware of busy-waits waiting for something to happen. Some devices (most notably certain floppy disk controllers -- why is is that everything about floppy disks is unilaterally disgusting) require that you write something to a register, wait for a bit to come high saying that the first bit has been digested, after which you can write some more information. This is typically done with code like while(ryaddr->ryics & RY_TR) == 0); This code comes from a particularly noxious device driver we have for a horrid floppy controller whose manufacturer I won't mention since I'm not feeling libelous today. Under certain poorly understood circumstances, the use of these floppy drives follows the following novel course of events: 1. User inserts disk, forgetting to install write-enable sticker. 2. User attempts to write to disk 3. User's terminal hangs 4. User can't get his terminal back, with control-C, control-\, or kill -9 from another terminal, because the process is sleeping down in the device driver and nothing, not even root, can kill it 5. User gives up and tries to get his floppy disk back. The door to the drive won't open... 6. User discovers that by powering down the floppy drive, the drive will relinquish his disk 7. User wonders why, when he emerges from the room containing the floppy drive, all the other users are complaining that the machine seems to be dead 8. The kernel is in fact in an infinite loop at high interrupt priority, waiting for the TR bit which is now never going to come, even when the floppy drive is powered back on, because the drive will have forgotten that it was in the middle of a transaction. These difficulties could be avoided if peripheral manufacturers would condescend to market controller boards with sane interfaces. Until then, though, if you have to write a device driver for a demented controller, please break out of the busy-wait loop after 100 iterations or so and return EIO or something. Yeah, you may dump the floppy user on the floor, but he deserves it for using floppies in the first place, and anyway he'll probably be able to get his disk out without a screwdriver, and all the other users won't have to wait for the machine to be manually halted and rebooted. Steve Summit tektronix!copper!stevesu P.S. Join the Coalition to Banish Floppies! They're slow; they don't hold enough data; they're unreliable; they have universally disgusting controllers; and people who use them bring the machine to its knees so I can't get any work done. Everybody should use 9-track magtape (and none of those grotty streaming drives, either). P.P.S. I know floppies and streamers are cheap. In both senses of the word. "You gets what you pays for."
marty@fritz.UUCP (Marty McFadden) (04/23/86)
In article <291@copper.UUCP> stevesu@copper.UUCP (Steve Summit) writes: >In article <234@Shasta.ARPA> alex@lancelot writes: >> >> Assume I want to busy loop in the kernel for 100 milliseconds, how >>many times (approx) should I go around a loop which increments an int? > > while(ryaddr->ryics & RY_TR) == 0); My advice is to be careful here!! The first question about how many times should one loop is NOT processor portable!! Say for instance, you decide to upgrade from a 68000 to a 68020 with cache. These 100 millisecond loops are no longer 100 milliseconds but can virtually take almost NO time at all :-) The second suggestion is okay, but I suggest that you also add some sort of timeout mechanism that comes along every few seconds or so and makes sure that you are not hung in that state. cheers. -- Martin J. McFadden {decvax, ucbvax}trwrb!felix!marty FileNet Corp. Costa Mesa, Ca.