<jdmiller(a)fas.harvard.edu>
this is the dude's email.
good luck.
>From: "Courtney Anne O'Keefe" <cokeefe(a)fas.harvard.edu>
>Reply-To: cs161-list(a)fas.harvard.edu
>To: cs161-list(a)fas.harvard.edu
>Subject: [cs161-list] helloo??
>Date: Thu, 13 Feb 2003 22:14:29 -0500 (EST)
>
>
>Prof. Seltzer mentioned today that someone named (I thought) "Steve
>Mitchell" or "Steven Miller" was looking for a partner..(?)
>If you might possibly be that person (or, for that matter, any other
>person) and are STILL looking for a partner.. email :]
>
>thanks!
>courtney
>
>
>
>_______________________________________________
>cs161-list mailing list
>cs161-list(a)fas.harvard.edu
>http://www.fas.harvard.edu/mailman/listinfo/cs161-list
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
Prof. Seltzer mentioned today that someone named (I thought) "Steve
Mitchell" or "Steven Miller" was looking for a partner..(?)
If you might possibly be that person (or, for that matter, any other
person) and are STILL looking for a partner.. email :]
thanks!
courtney
hello coders (and codettes):
a bit of a menagerie of things follows, most of it related to asst1.
1) many people have noticed that when running catsem/catlock/stoplight
they return to the menu before the spawned threads are finished printing.
this is not ideal behavior (the best reason being that you should be
cleaning up after your cat/mouse/car threads) and there is a
straightforward solution using one of the synchronization primitives you
have been learning about.
NB: you may use essentially the same solution for this problem for each
synch problem (i.e., the usual rules for catlock/sem don't apply to the way
that you synchronize the return of the driver thread).
2) please have the cat and mouse threads loop a few (10, 20) times before
exiting so that you get a good idea of what is going on.
3) kprintf() is atomic, but only if you have working locks. if you see
printouts from two seperate threads interspered your locks are either
unimplemented or broken.
as a corrolary to this, you cannot use kprintf() to debug your locks (you
shouldn't be using kprintf() to debug anything in this course... use GDB).
4) to make stoplight a bit more clear: one big lock is NOT an acceptable
solution to this problem.
finally, one mailing list related item:
5) professor seltzer touched on this in class today, but it is worth
repeating: please be careful about how you use cs161@fas. the teaching
staff is here to help you, but our efficiency is maximized when you do
your best to help us help you. this normally includes:
-- checking the website for patches/updates
-- checking the website for pertinent handouts
-- reading the assignment carefully again
-- trying to the best of your ability to solve the problem yourself
when you approach a TF remember that they are walking straight into the
middle of your problem, so be prepared to supply context: what isn't
working, why do you think that it isn't working, what have you done to try
and rectify the situation and what has been the results of your efforts.
the more information you can give us the more helpful we can be.
office hours tonight: dave (8-10), me/gwa (10-12), both in the science
center basement.
a demain,
-gwa-,on behalf of the cs161 course staff
By request, I have compiled ircII (the basic Unix irc client) on ice.
You can run it as "cs161-irc".
I have not built it on "nice", but may in the future.
--
- David A. Holland / dholland(a)eecs.harvard.edu
Hello valiant cs161'ers,
This is a gentle reminder that you must section by this Friday. You must
register for the same section as your partner. You should tell us your
partner's name and group name in case you haven't already done so. The
link to the sectioning program is:
http://www.section.fas.harvard.edu/
Distance students still must section, but should do so by emailing the
course staff your (you and your partner's) preferences and animal name.
The section times are:
Mon 1-2
Tue 3-4
Tue 4:30-5:30
Tue 7:30-8:30
-jonathan
Hi,
I've looked through the interrupt code, but I don't see why in some cases
you want to crash the system if a thread is trying to do something in an
interrupt handler. For example, in P, why do we assert that in_interrupt is
0?
Thanks,
Dave
Formally, the volatile tag prevents the compiler from reordering the
accesses to the object so marked, or optimizing away accesses that it
thinks are redundant. For instance, if you wrote code to busy-wait on
a global variable, like this:
while (gFlag==0) thread_yield();
an optimizing compiler might convert it to something like
if (gFlag==0) {
while (1) thread_yield();
}
that doesn't work, because the compiler doesn't know about (and isn't
required to account for) the thread that's going to change gFlag.
Making gFlag volatile tells the compiler it can't (correctly) optimize
away the repeated access to gFlag, and keeps it from breaking the
code.
This is all very well, but it turns out that, formally, everything
that's ever shared by more than one thread, or by one thread and an
interrupt handler, needs to be declared volatile, because (formally)
the compiler's allowed to analyze the entire code flow and optimize
even widely separated memory accesses.
In practice, we don't mark everything volatile, because it causes an
unnecessary penalty. (Within a critical section, it's quite correct to
optimize memory accesses.) Unfortunately, however, there's no portable
way to tell the compiler where variables become "stable".
So what we generally do, since most compilers do very little
inter-procedural analysis, is only mark things volatile if we expect
their values to change during the course of a single call to a single
function that uses them. This might be a loop like the one in P(), or
a case like this:
lock_acquire(mylock);
tmp = variable_protected_by_mylock;
lock_release(mylock);
stuff;
lock_acquire(mylock);
tmp = variable_protected_by_mylock;
lock_release(mylock);
where you know that the value might have changed and you want the new
value. (Code like this isn't very common.)
Systems that care deeply about every last cycle of performance often
have compiler-specific or otherwise non-portable hacks to allow
finer-grained control. I predict that as compilers get smarter, and
multithreaded programs become increasingly common, some finer-grained
mechanism will eventually be standardized in C or some successor of C.
I hope the above makes sense. It's actually a somewhat subtle and
delicate issue, and we probably should be discussing it in lecture.
--
- David A. Holland / dholland(a)eecs.harvard.edu
On Mon, 10 Feb 2003, Alexandra (Sasha) Fedorova wrote:
> > on the volatile qualifier, I am still not totally clear on when it should
> > and shouldn't be applied: for example - if one of our newly created
>
> A variable should be declared volatile if there is a big chance that it
> will be accessed by multiple threads within a short period of time. By
> declaring it volatile, you tell the compiler not to optimize it - some
> compiler optimizations may result in threads seeing inconsistent variable
> state. Look at the semaphore declaration structure - you will get the
> idea.
sasha is write, except that the time frame is not important.
even if a variable changes once per day in a way that gcc can't understand
you HAVE to mark it volatile. otherwise gcc will get all smart on you and
start eliminating things and you don't want that.
volatile doesn't describe how OFTEN a variable is accessed, it just
informs gcc that it isn't smart enough to understand HOW it is accessed
and so it should make any assumptions about it's value or do any clever
optimizations.
i can try to hack up an example of gcc being smart and how using
volatile eliminates that if people are curious.
-gwa-
>
> Hi. In 5.2.1 it is somewhat confusing that the question 1 says
> that these are code samples for threads that use "binary semaphores", and
> yet the code declares *master, and *array as locks?
they should be binary sems.
geez... sorry... i wish i had caught this.
-gwa-
i was talking with some students tonight who were curious about where to
use ASSERT() and where to use if(panic)else.
the ASSERT() macro is going to do essentially the same thing as
if(panic)else. the one advantage to using it though is that when your
system is fully debugged (keep dreaming... ;-) you can turn of the
ASSERT()'s and your code will be a bit faster.
just something to keep in mind on asst1.
good luck coding,
-gwa-
