Subject:
|
bugs in Rich Drushel's lock_process() library
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Thu, 2 Nov 2000 12:17:56 GMT
|
Viewed:
|
971 times
|
| |
|
|
A couple of weeks ago, students in my Autonomous Robotics course found some
bugs in my lock_process() library code. lock_process() and unlock_process()
were intended to work like hog_processor() and defer(), except to allow a
variable duration of process locking (up to 49 days!). The hope was that this
would obviate the need for a process which wanted to seize long-term control of
the CPU to have to kill_process() everything else that was running, and then
restart it after the need for the lock was over.
The following serious limitations make it really hard to use lock_process() in
its current state:
1) defer() actually will cause escape from lock_process(). So, any
code which tries to be multi-process-friendly and uses defer() to
avoid a foreground busywait (like my pseudorandom number generator
in random.c), will break the lock. Since defer() is an internal
function in IC (not a library function itself written in IC), I
have to create a new version, defer2(), which has suitable wrapper
logic around it to look at the global _LOCK_PROCESS flag and *not*
do a defer() if it's set. Note that the new version of msleep() that I
posted to the mailing list a few months back, which uses defer()
rather than a busywait, also causes escape from lock_process().
(2) printf() hangs a locked process. This is the biggy, and I bet that
this is what's causing your problems. printf() is implemented as
a printing daemon, and any process calling printf() just puts
characters into a FIFO buffer, serially. Currently, lock_process()
stalls this daemon, so nothing can get printed. I have to do some
digging to try to fix this. hog_processor() also stalls the printf()
daemon, but the lock runs out at 256 msec and the process scheduler
always manages to sneak in another process to keep the whole program
from stalling.
My short-term advice is to code around limitation (1) and avoid
using printf() during a lock_process for limitation (2). (2) is very
unfortunate, because you'd really like to see status info on the LCD
screen. Long-term, I will find some way to fix it...hopefully before the
end of the current semester.
I apologize for not posting a notice immediately...it wasn't until Steve Law
inquired this morning that anybody has ever asked about the lock_process()
library, so I thought I could sit on it until I'd fixed the bugs. I didn't
realize that anybody else was trying to use the code.
*Rich*
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
