After I am done running my whale program, the system just hangs there. I am calling thread_exit as each thread comes to an end. Are there any other calls?
Easy, stupid question:
Just because I'm going back and (re)verifying my original import worked,
what is the correct operation of the threads test?
Nick
I noticed a somewhat unexpected behavior from os161 - when you execute the
user program several times in a row the global variables that are
initialized at declaration do not get re-initialized. This may give some
weird behavior.
David, is this how things should work?
Sasha
Hmm... Apears to be working fine in mine.
Georgi
At 01:39 AM 2/21/2001 -0500, you wrote:
>are locks allowed to be destroyed while someone is still holding on to
>them? it seems like a bad idea to allow this, but some vfs code
>(vfslist.c) seems to be doing so. I fail an assertion (upon bootup and
>immediate exit) if i try to make sure all locks are released before being
>destroyed.
>
>cy
>
>_______________________________________________
>cs161-list mailing list
>cs161-list(a)fas.harvard.edu
>http://www.fas.harvard.edu/mailman/listinfo/cs161-list
are locks allowed to be destroyed while someone is still holding on to
them? it seems like a bad idea to allow this, but some vfs code
(vfslist.c) seems to be doing so. I fail an assertion (upon bootup and
immediate exit) if i try to make sure all locks are released before being
destroyed.
cy
A. Student (astudent(a)fas.harvard.edu) wrote:
> > o In this problem (and the others), you are welcome to randomize the
> > start order of the threads. (Your solution must, of course, work
> > for any start order.)
>
> how would one do this?
Something like this:
void
cannibals(void)
{
int i, nm=0, nc=0;
for (i=0; i<NMC*2; i++) {
if (random()%2==0 && nc < NMC) {
t = thread_fork("Cannibal Thread", NULL, nc,
cannibal);
nc++;
}
else {
assert(nm < NMC);
t = thread_fork("Missionary Thread", NULL, nm,
missionary);
nm++;
}
if (t==NULL) {
panic("cannibals: thread_fork failed\n");
}
}
}
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Please make the following change to synch.c.
(Replace the line marked - with the line marked +. You can also save
this message to a file, go into src/kern/thread, and feed this message
to "patch", like this:
patch < mailfile
That will make the change for you, unless you've changed that line of
synch.c yourself.)
Index: synch.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/src/kern/thread/synch.c,v
retrieving revision 1.5
diff -u -r1.5 synch.c
--- synch.c 2001/02/02 10:12:03 1.5
+++ synch.c 2001/02/20 01:32:35
@@ -118,7 +118,7 @@
struct cv *
cv_create(const char *name)
{
- struct cv *cv = kmalloc(sizeof(cv));
+ struct cv *cv = kmalloc(sizeof(struct cv));
char *myname = kstrdup(name);
if (cv==NULL || myname==NULL) {
panic("cv_create: Out of memory\n");
Red-faced,
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
these problems really could have been better written.
"When a cannibal or a missionary arrives at the river bank, he must get on
the boat if there is room and the combination of people on the boat is
valid."
what on earth does this mean? it sounds like you want to just handle
things on a boat-by-boat basis, having cannibals and missionaries
competing for the right to get on and then you deal with incompatibilities
as they show up.
but you can easily get into deadlock conditions if you don't look at the
people ON the bank. and if you do this there are VERY trivial solutions.
so how are we to interpret the above. any ideas?
-gwa-
Clarifications for the synchronization problems in asst1:
whalemating:
o It is acceptable to have the matchmaker be "active" for the entire
course of mating, or simply for the matching process. Remember
that this code should use semaphores.
o Each particular whale need only engage in an act of mating once,
regardless of role. They may then exit, and go eat plankton or
do whatever these whales do. Since there's an equal number of
each type of whale, this keeps things clean.
students & tfs:
o messages should be printed only when a thread "does" something --
asks or answers a question. but whenever a thread prints something
it should identify itself.
o students should allow other students to ask questions in between
each question they ask.
o students should exit after they've asked all their questions.
o tfs should know when all the questions are asked, and exit. it is
fine if some tfs have answered more questions than others, that's
life. it is not okay if any tfs exit before all the students
have.
cannibals & missionaries:
o It is possible to come out at the end with nobody left on the bank
but two cannibals and a missionary, who cannot then get into the
boat and are stuck. This is ok.
o Ideally, your code should detect this condition, print a message,
and have the stuck threads exit, though it's ok if it doesn't.
o It is possible to arrange things so that this situation does not
occur. To do so, your code will need to know the number of
missionaries that will be arriving. (You should be able to
demonstrate to yourself that you cannot avoid this case otherwise.)
If you wish to implement this feature, you may use that number,
but you shouldn't use that number for other purposes.
o You need not handle cases where the total number of threads
(missionaries and cannibals together) is not a multiple of three.
o In this problem (and the others), you are welcome to randomize the
start order of the threads. (Your solution must, of course, work
for any start order.)
We (the TFs) apologize for not getting these clarifications out more
quickly.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
As you've probably all noticed, kprintf() is not atomic, that is,
messages printed from different threads can become intermingled on the
console.
The recommended way to correct this problem, if you consider it a
problem, is to create an additional function, lkprintf, that does the
same thing as kprintf but acquires and releases a lock around the
actual printing operation.
Note that while it's possible to add a lock to kprintf itself, for
various reasons(*) it's somewhat tricky - it'll be much easier to make
a separate function.
If possible, please *don't* synchronize kprintf by disabling
interrupts around/within it; this causes it to loop polling the
output device on every character, which wastes cpu and doesn't give
other threads the opportunity to run.
(*) There are two primary reasons: (1) kprintf is called very early in
boot, before it's possible to kmalloc, so initializing the lock is
problematic, and (2) kprintf is called from interrupt handlers, where
it's not safe to wait to acquire a lock.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
