hi courtney:
this is an excellent question, so i'm going to post a reply to the entire
list.
if you examine the pseudo-code for the implementation of a mutex on page
113 of tannenbaum you'll see what the problem is. when a thread is unable
to acquire a mutex it calls thread_yield(), surrendering the processor but
remaining runnable. the next time the thread gets a chance to run it will
try to acquire the mutex again, if failing calling thread_yield() again.
so for a resource (such as a tape drive) that could be unavailable for
long periods of time, if you watched you would see this type of pattern
for a thread trying to acquire a mutex to work on the tape drive:
thread 1 - try to get mutex. fail.
...other threads run...
thread 1 - try to get mutex. fail.
...other threads run...
thread 1 - try to get mutex. fail.
...other threads run...
on and on and on and on.
the obvious problem with this solution is that we waste valuable processor
cycles while thread 1 repeatedly tries to acquire this mutex.
we'd like to do something more clever, and condition variables allow us to
do that. because when a thread tries to acquire a condition variable and
fails it goes to sleep, only awakened when the thread that holds the
condition variable signals. so in this case thread 1 could go to sleep
for the minutes required for some other thread to finish using the tape
drive and then be notified when it is done.
you can see that there is a considerable amount more overhead associated
with condition variables because we have to keep track of who is waiting
and worry about waking them up at the appropriate moment. so here's the
fundamental tradeoff:
mutexes - use to protect SMALL critical sections and resources that are
not held for very long. lightweight.
condition variables - use to more efficiently protect LARGE critical
sections (although your critical sections should NEVER be big enough that
you need to protect them with a CV) and resources that are held for a
while (tape drives being one example).
i hope that this helps.
-gwa-
On Sat, 8 Feb 2003, Courtney Anne O'Keefe wrote:
>
> Hello,
>
> on p.698 (chapter 10 - unix) of Tanenbaum it says that "MUTEXES are
> intended for short term locking, such as protecting a shared variable.
> they are not intended for long-term synchronization, such as waiting for a
> tape-drive to become free. for long term synchronization, CONDITION
> VARIABLES are provided"
>
> ..I have read chapter2 of Tanenbaum, but am still not clear on why mutexes
> are intended for short-term and condition variables for long-term.. is
> there some specific example that would illustrate the reasoning behind
> this choice?
>
> thanks!!
> courtney
>
yes, it is a typo, and you're right about how to fix it.
whoops... none of the course staff caught that one, nice job :-).
-gwa-
On Sun, 9 Feb 2003, Courtney Anne O'Keefe wrote:
>
> hi. in question 5.2.1, what do "mutex" and "data" refer to? should they
> actually be replaced with "master" and "array", which are defined right
> above them? (eg, is this a typo?)
>
> thanks!
> c
>
hello everyone:
just a few things:
1) sections and office hours start this week. check the course web site
for times and locations. since section assignments aren't finalized
yet this week's sections are open so feel free to attend as many as you
like.
2) mailing list usage:
just a quick review of the various lists that we've set up:
cs161@fas - - - - - - - -
goes to the course staff. this can be used for questions regarding
assignments. if the question is suitably general (and you don't
mind... please tell us if you do) we'll also post replies to
cs161-list@fas so that the entire class can benefit.
you can also use this for any other issues that the course staff needs to
know about.
cs161-list@fas - - - - -
goes to the entire class. two purposes: 1) allow us (the course staff) to
communicate with you (the class); 2) allow you (the class) to communicate
among each other. sometimes at 4AM when you can't get a hold of the
course staff (we do sleep from time to time) your fellow students will be
a great resource.
please note that the "Reply-To" address for cs161-list@fas is set to the
entire list, so if you are replying to mail coming from the course staff
please either adjust the "Reply-To" field or forward it to cs161@fas.
good luck with asst1! feel free to email with any questions.
-gwa-, on behalf of the course staff
check out
http://www.programmersheaven.com/articles/pathak/article1.htm
that seemed like a pretty good explanation.
essentially using the volatile keyword allows you to tell the C compiler
not to try and be too clever about optimizing that particular variable
because it can change it ways that the C compiler isn't smart enough to
figure out.
ok, here's an example from my fav (linux):
from timer.c (http://lxr.linux.no/source/kernel/timer.c#L68)
<snip>
68 unsigned long volatile jiffies;
<snip>
from main.c (http://lxr.linux.no/source/init/main.c#L155)
160 void __init calibrate_delay(void)
161 {
162 unsigned long ticks, loopbit;
163 int lps_precision = LPS_PREC;
164
165 loops_per_jiffy = (1<<12);
166
167 printk("Calibrating delay loop... ");
168 while (loops_per_jiffy <<= 1) {
169 /* wait for "start of" clock tick */
170 ticks = jiffies;
171 while (ticks == jiffies)
172 /* nothing */;
173 /* Go .. */
174 ticks = jiffies;
175 __delay(loops_per_jiffy);
176 ticks = jiffies - ticks;
177 if (ticks)
178 break;
179 }
does anyone want to venture a guess at what this code is doing?
in any case, notice that <jiffies> is declared volatile. what would the C
compiler do to the code above if it was not? the reason that <jiffies> is
declared as volatile is because it is updated at timer interrupts (i
think).
hope this example helps.
-gwa-
On Sun, 9 Feb 2003, Brian Greenberg wrote:
> Hi,
>
> Can someone give me a quick rundown on what the volatile keyword does in
> C? I've looked in K&R and the explanation wasn't very illuminating.
> Maybe you can point me to a better source?
>
> Thanks a lot,
> Brian
>
oops.
try:
replace "Whalemating" with "Cat Problem with Semaphores"
replace "Pizza..." with "Cat Problem with Locks"
replace "Harry..." with "Stoplight Problem"
<sigh>
sorry, again, my mistake.
-gwa-
On Sat, 8 Feb 2003, David Troiano wrote:
> Hi,
>
> I see another update for menu.c. The menu output (around line 443) still
> has old stuff:
>
> 446 #if OPT_ASST1PROBS
> 447 "[1a] Whalemating ",
> 448 "[1b] Pizza Participation ",
> 449 "[1c] Harry Potter Fans ",
>
> What should these labels be changed to?
>
> Thanks,
> Dave
>
To make it easier for people in the class to communicate with each
other, we have set up a private IRC server. This is intended primarily
for the distance/extension students, who otherwise have no real-time
communal forum, but everyone is welcome.
We will hold virtual office hours on the server at the same time we're
holding office hours in the terminal room. If this proves not to work,
we'll schedule other times or something as needed.
The server is at port 6667 (the standard IRC port) of the machine
dolittle.eecs.harvard.edu. The channel we've set up for general use is
called "#talk"; in most IRC clients you would type "/join #talk" to
participate, after connecting.
IRC clients of various kinds are available for all major platforms.
There is no client installed on ice (although there may be on "nice"),
but if there's demand I can put one in ~cs161.
It's not unheard of for bad guys to distribute evil hacked versions of
IRC clients, so do exercise ordinary caution if downloading a client
to make sure you're getting it from the official distribution site.
And don't run "scripts" people give you unless you're sure what they
do.
If you haven't used IRC or other "chat room" software before, be
careful. It can be addictive and it's easy to waste your whole life on
it. It's not an accident that some people refer to IRC as "I Repeat
Class"... We wouldn't want that to happen to anyone here.
The cs161 IRC server shouldn't have enough going on that this becomes
a problem. However, if you find yourself thinking about going
elsewhere (to other servers) to look for more people to talk to, in
all seriousness: stop and ask yourself if it's something you really
want to get into.
--
- David A. Holland / dholland(a)eecs.harvard.edu
I apologize for the amount of mail that you have received from us in
the past 2 days, but this is a side effect of trying to set things up
right in the beginning of the semester. So please bear with us.
This message is important for you if you are USING AN E-MAIL ADDRESS OTHER
THAN THE ONE ON FAS TO POST MESSAGES TO CS161-LIST. If you are, the
messages will not get automatically posted, but will be forwarded to the
list administrator for consideration. This may delay the appearance of
your messages on the list. This configuration is in place in order to
prevent bad people from sending junk mail to the list.
In order to avoid the delay in arrival of your messages, it is necessary
to subscribe you to the list with the e-mail that you are going to use
when posting messages.
If you are using some non-fas address (such as yahoo or hotmail) to talk
to the list, give this address to me, so that I can add it in.
-- Sasha
Dear students,
Do not forget that you have to do 4 things by Friday, Februrary 14th (in
addition to Assignment 1):
1. Find a partner for assignments 2-5.
2. Select an animal name for your group.
3. E-mail TFs (cs161(a)fas.harvard.edu) the fas login names of yourself and
your partner, and your group name. Only one of the partners has to do
this.
4. CS161 students must section online. CSCI E-251 students must tell us
whether they are going to physically attend sections and if they are,
which section they are planning to attend.
Sasha on behalf of the course staff.
hello cs161 students:
there were an unusually large number of you that had problems submitting
asst0. since there WERE such a large number, some of the blame must be
ours, but really the advice that we're going to give you comes down to
RTM. we decided not to penalize the large number of you that made
submission errors this time, but next week we will not be so lenient.
<please> go through the submission handout on the wedsite carefully,
preferably before five minutes before you have to submit. here are a few
pointers though taken from the mistakes that people made this time:
1) first, always always always "cvs commit" BEFORE you submit. in
addition remember to "cvs add ; cvs commit" any new files. you are going
to the time and energy to modify all this code... if the changes don't
make it to us, you are going to be unhappy. just get in the habit, even
if you think you've committed everything, of running "cvs commit" from the
lowest level source directory before you submit just to make sure that you
haven't missed anything.
2) after you export your tree into a subdirectory of asstX and make the
tarball DELETE the exported tree. the point of making a compressed
tarball is so that we can get your exported tree in a more compact form.
we don't want the whole tree as-is.
3) we ALWAYS want copies of a) a cvs diff of your src tree prepared as
described in the submission handout (usually diff-ed against the last
assignment's release) and b) your sys161.conf file. the diff make our job
easier by making it easy to see where you made changes. sys161.conf shows
us how you were configuring the simulator if we need to try and reproduce
something.
ok, sorry for the extending berating. now we'll move on to some
self-berating: we are very truly and deeply sorry for making you print out
50 pages of make output. this probably seemed idiotic to you, and it
also seemed idiotic to us, actually, but we had no way of informing the
class and chose to leave things as they were. sorry.
best wishes for a wintery weekend,
-gwa-, on behalf of the cs161 teaching staff
people have been reporting that they are having trouble running make
depend and make for asst1.
this is our (read my) fault. please accept the following diff as
recompense. it is quite small and should be easy enough to apply by hand
if you are uncomfortable using patching utitilies.
please keep us abreast of any further problems with the assignment as it
progresses.
-gwa-, on behalf of the cs161 teaching staff
Index: asst1/stoplight.c
===================================================================
RCS file: /home/w/e/werner/cs/cs161/cvsroot/src/kern/asst1/stoplight.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 stoplight.c
216c216
< NULL,
---
> NULL
Index: conf/conf.kern
===================================================================
RCS file: /home/w/e/werner/cs/cs161/cvsroot/src/kern/conf/conf.kern,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 conf.kern
433,435c433,435
< optfile asst1probs asst1/library.c
< optfile asst1probs asst1/pizza.c
< optfile asst1probs asst1/whalemating.c
---
> optfile asst1probs asst1/catsem.c
> optfile asst1probs asst1/catlock.c
> optfile asst1probs asst1/stoplight.c
Index: main/menu.c
===================================================================
RCS file: /home/w/e/werner/cs/cs161/cvsroot/src/kern/main/menu.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 menu.c
499,500c499,500
< { "1a", catsem },
< { "1b", catlock },
---
> { "1a", catmousesem },
> { "1b", catmouselock },
