Hi, everybody.
I've just released another patch to OS/161. It fixes a few minor
mistakes, some glitches in the test code, and should make the problem
with infinitely repeating __start stack frames in gdb go away. It also
fixes one significant bug that occasionally caused weird crashes after
system halt.
Please apply this patch *after* submitting assignment 1 and *before*
tagging your repository for the beginning of assignment 2. (That way,
these changes won't appear when you submit your assignment 2 diffs,
which makes things easier for us.)
You can get the patch from the downloads page of the web site. Basic
directions for applying patches are posted there. Don't forget to cvs
commit the resulting changes before you do anything else. If you need
help, contact cs161@fas.
This is patch #2 against OS/161 1.03. If you did not get and apply
patch #1, please apply it as well.
(The result of applying both patch #1 and patch #2 to OS/161 1.03 is
OS/161 1.04, which is also posted on the web site for completeness.
When the solution set for assignment 1 is released, it will have
version number 1.04 as well to indicate that it already includes these
patches.)
Dave.
--
- David A. Holland / dholland(a)eecs.harvard.edu
Does a reader have to check a book out through a librarian? It says
explicitly so for checking books in, but I'm being nitpicky about checking
them out.
Thanks,
Josh
There have been a number of questions regarding the behavior of
kprintf with respect to locks and interrupts.
Specifically, kprintf does not stop to acquire the kprintf lock if
interrupts are disabled.
This is quite deliberate. Code that is running with interrupts off
normally does so because an interrupt, including but not limited to an
interrupt that triggers a context switch, would cause incorrect
execution. It is therefore likely that context switches while calling
kprintf from such code, as might be triggered by waiting to acquire a
lock, would also cause incorrect or unexpected behavior.
Therefore, things have been arranged so that kprintfs called when in
interrupt handling routines or called when interrupts are disabled are
atomic. In fact, console I/O is handled differently at the device
driver level as well under these circumstances to ensure this property.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
After answering the email to cs161@fas, I saw the same question pop up to
the list, and so here is my answer:
> The following code is from kprintf.c:
>
> if (kprintf_lock != NULL && !in_interrupt && curspl==0) {
> lock_acquire(kprintf_lock);
> }
>
> My question is: Why do we not acquire the lock when interrupts are off
> (curspl > 0)?
A good question. I think the answer is as follows.
Suppose interrupts are off -- clearly this is for a reason, like you're
trying to render some operation atomic. Now, if you try to acquire the
lock, but someone else is holding the lock, what will happen? Depending
upon your lock implementation, you will probably thread_sleep(), causing
your thread to go to sleep until that lock is acquirable. This will lead
to interrupts being prematurely turned off, and your operation not being
correctly spl-synchronized.
This is most likely undesired behaviour. As such, if you have interrupts
on, you synchronize kprintf() output with an advisory lock. If they're
off, then you just bulldoze through and print out, without regard for the
lock.
Either way, I really think it's sort of nasty to kprintf() while
interrupts are off, as Sasha pointed out. Avoid it if at all possible. I
understand that for the librarian problem that just passed, it may not
have been easily avoided.
hope this helps,
-mike
Hi,
i've commited the changes using cvs commit and itmodified the files.but
when i executed cvs diff, it didn't display any differences.please let me
know how should i create asst1.diff.
Thanks,
Aparna.
i was chugging along, running the kernel, going thru
the menu to run the tests on locks and condition
variables.
tests failed - code fix - make - make install -
re-run
iterate...
during the last iteration, i moved a member variable
from the lock struct to the semaphor struct, and now
when i run the kernel, i don't even get to the menu.
all i get is:
sys161: System/161 release 0.97, compiled Jan 31 2002
12:56:06
and then it seems to hang...
is it possible that modifying semaphor is responsible?
ps:
i did a ps, and theres only one sys161 kernel job
running.
thanks!
__________________________________________________
Do You Yahoo!?
Got something to say? Say it better with Yahoo! Video Mail
http://mail.yahoo.com
Yeah, I got this too. It's because kprintf doesn't acquire a lock when
interrupts are off. Any ideas why kprintf is written that way?
~James
At 06:10 AM 2/15/2002 -0500, Joshua John Forman wrote:
>Hey all,
>
>Does anybody know how to fix this problem:
>
>ReReader 1 returned book 4
>aLibrarian 1 returned book 4
>der 7 checked out book 4
>ReaReader 7 returned book 4
>dLibrarian 0 returned book 4
>er 2 checked out book 5
>ReaReader 2 returned book 5
>derLibrarian 1 returned book 5
> 4 waiting for book 5
>Reader 8 waiting for book 5
>
>where kprintf seems to be all over the place? I'm fairly sure the code
>itself works, it's just the printing that's off.
>
>Thanks,
>
>Josh
>
>_______________________________________________
>cs161-list mailing list
>cs161-list(a)fas.harvard.edu
>http://www.fas.harvard.edu/mailman/listinfo/cs161-list
From the output below it seems clear what's going on. and you are ok
without the exit messages. If you want to be fancy, you might as well put
them in.
-Georgi
At 03:31 PM 2/14/2002 -0500, Kitty Lin Leung wrote:
>I'm still confused about the printout for the whalemating problem. In one
>of mike's previous e-mails, he had the whales print when they were mating
>and then again when they exited. In my functions, when they succesfully
>mate, the threads exit, so it seems that two messages are redundant. Do
>we need the second set, or is the following output acceptable?
>
>male whale #1 mated
>female whale #8 mated
>matchmaker whale #5 helped in mating
>male whale #9 mated
>female whale #9 mated
>matchmaker whale #4 helped in mating
>male whale #2 mated
>female whale #3 mated
>matchmaker whale #3 helped in mating
>male whale #5 mated
>matchmaker whale #2 helped in mating
>female whale #0 mated
>male whale #7 mated
>female whale #7 mated
>matchmaker whale #8 helped in mating
>
>-Kitty
>
> ----------------------------------
>| kleung(a)fas.harvard.edu |
>| Currier House T208/ Box 172 |
>| Class of 2003 - Computer Science |
> ----------------------------------
>
>_______________________________________________
>cs161-list mailing list
>cs161-list(a)fas.harvard.edu
>http://www.fas.harvard.edu/mailman/listinfo/cs161-list
At 04:02 PM 2/14/2002 -0500, Charles Duan wrote:
>Hi,
>
>Is it ever possible for different threads to call cv_wait with different
>locks? I'm pretty sure that two threads can't simultaneously wait on one
>cv while holding different locks, but if no one is waiting then
>(theoretically) it should be okay, although I'm thinking strange things
>might happen.
Technically, there is no reason why you can't do that, but it does not make
much sense and probably bad things will happen. Think about what the lock
is actually protecting. On the other hand, it is often the case that one
uses the same lock for different CVs.
-Georgi
At 04:13 PM 2/14/2002 -0500, Bryan Choi wrote:
>So i was wondering how the students know there is no more pizza coming. Do
>they get to keep track of the global variables NPIZZAS and NPIZZAMAKERS
>and decrement them appropriately? Or can we use another global variable to
>see how many pizzamakers are on duty?
>Or is there some other way that doesn't involve globals?
Since you probably want to share this information between threads global
variables are the way to go. It's up to you to decide how many and how to use.
-Georgi
