cs161-list February 2001

cs161-list@lists.fas.harvard.edu

18 participants
33 discussions

by Zubin Teja

Did anyone get the following output when trying to run their kernel: sys161: System/161 release 0.92, compiled Feb 12 2001 18:25:33 sys161: 159205 cycles (34217k, 0u, 124988i) in 0.011719 seconds (13.5852 mhz) sys161: 0 irqs 0 exns 0r/0w disk 0r/0w console After which the program exits? --Zubin

23 years, 2 months

interpretation question

by Michael Tucker

Hi, In the Students and TFs problem, do we need to print out when the thread for the students and TF's is first run? They say that "each thread should identify itself and print a message when it has succeeded in submitting a question..." Does this mean there are two actions, ID'ing (at startup) and printing a message when it has succeeded... or does this mean that when it succeeds it should identify itself and print out what it did? Thanks, Mike

23 years, 3 months

Re: [cs161-list] various synch questions

by Zubin Teja

>1) can there be more than two whales mating at any given time? >essentially, what does it mean for a matchmaker to be 'active'? Since there can only be one active matchmaker, and the matchmaker picks the female and must wait until that female is done mating, I think that there can only be two whales mating at a time. >2) can a student submit a second (or third, etc) question before they >receive an answer to the first? Well, the errata said that we don't have to print out when the student gets an answer, so my thinking is that once the student has submitted a question then they don't have to worry about it anymore. I think you can also assume that the questions are not dependent on each other. >hope everyone is having fun. > >-gwa- > >_______________________________________________ >cs161-list mailing list >cs161-list(a)fas.harvard.edu >http://www.fas.harvard.edu/mailman/listinfo/cs161-list

23 years, 3 months

Re: OS/161 version? (fwd)

by David Holland

A. Student (astudent(a)fas.harvard.edu) wrote: > Hi, > > I was wondering how I can check to make sure that my cvs import/cvs > update worked properly? When I ran the commands I didn't get any errors, > so I thought it worked fine, but I was just discussing the queue functions > with a friend, and his queue.c file has q_remhead and q_addtail, while my > version has q_pop and q_push. How can I fix this? (or how can he fix his?) Version 1.00 of the code renamed the queue functions to "remhead" and "addtail". Also, version 1.00 should have, in mi_switch in thread.c, the logic /* * We set curthread to NULL while the scheduler is running, to * make sure we don't call it recursively (this could happen * otherwise, if we get a timer interrupt in the idle loop.) */ if (curthread == NULL) { return; } cur = curthread; curthread = NULL; If your source tree has neither of these things, your import didn't work. If your source tree has both of these things, you're probably ok. If your source tree somehow has one of these changes but not both, something strange happened (and you should probably contact a TF.) -- - David A. Holland | VINO project home page: dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino

23 years, 3 months

various synch questions

by gwa

yo. just wondering how people are treating the various questions, which are not necessarily all that well written: 1) can there be more than two whales mating at any given time? essentially, what does it mean for a matchmaker to be 'active'? 2) can a student submit a second (or third, etc) question before they receive an answer to the first? hope everyone is having fun. -gwa-

23 years, 3 months

volatile

by Jeff DeSoto

Hi guys, can you just explain a little more about what the volatile keyword does? jeff

23 years, 3 months

Re: [cs161] hz issues

by gwa

yah...this is kind of the behavior that i expected once i thought about it. so, on a real system you don't want to over-clock things this way, but you obviously don't want to dole out timeslices that are too large or you have a hard time maintaining the illusion of multi-programming. i'm not sure about the gray area because i haven't (yet) run any tests in that region, but how in general is this type of decision made as regards to the frequency of pre-emptive interrupts? also another random question for sys161 designers... is there any hope of implementing some sort of interrupt masking on sys161 or should i forget about it? -gwa- On Tue, 13 Feb 2001, Amos Blackman wrote: > Geoff, > > First of all, this seems like a good sort of post for the cs161-list@fas > list, since it is non-specific and exploratory. I'd highly recommend > posting it there and generating discussion. > > The simple answer to your question is that busywaiting is essentially > always bad. The slightly longer answer is that what happens when you > increase the HZ of OS/161 is that each thread runs for a shorter amount of > time before it's unscheduled. So, with an artificially high hardclock, > your busy waiting threads are essentially not busywaiting (they run barely > long enough to check the condition maybe once or twice). This is not a > situation you would ever want in a real system, because context switching > is relatively a very expensive operations (once most of your threads are > processes this will become apparent), and you don't want to introduce this > kind of overhead too often. > > -amos > > On Tue, 13 Feb 2001, gwa wrote: > > > hello: > > > > i've implemented locks in two different ways: one uses busywaiting > > (spinlocks) and the other uses same methods behind the semaphore > > implementation (what i called stampedelocks). > > > > i found it interested that when i first tested these against each other > > they seemed to have equal running times. i eventually figured out that > > this was caused by the high clock speed that is built in to assignment 1 > > (10000Hz vs. 100), and once i reduced the clock speed the stampedelocks > > ran much faster, as expected. (attached at the bottom are results of > > timing the lock tests at the two different clock speeds) > > > > i'm kind of curious about why this would be the case, and what this > > implies about the relationship between something like implementation and > > clock speed. it seems like (and i haven't tested this), if you set the > > clock speed even HIGHER you could get the spinlock implementation to > > actually perfom better than the stampede locks, because of the overhead > > associated with thread_wakeup(), especially with large numbers of threads. > > is this type of behavior a function of the primitive scheduler that we > > have, or is it more general? > > > > another question: is there ever a case where one would WANT the simple > > semantics of thread_wake() rather than introducing some form or wait > > queues? > > > > cheers > > -gwa- > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > 1. spinlocks > > > > @100Hz ---------------------------- > > > > Starting lock test... > > #lock threads: 100, #loops: 100 > > Lock test done. > > Shutting down. > > The system is halted. > > > > real 38.2 > > user 18.6 > > sys 0.1 > > > > @10000Hz -------------------------- > > > > Starting lock test... > > #lock threads: 100, #loops: 100 > > Lock test done. > > Shutting down. > > The system is halted. > > > > real 137.4 > > user 60.1 > > sys 0.9 > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 2. stampedelocks > > > > @100Hz --------------------------- > > > > Starting lock test... > > #lock threads: 100, #loops: 100 > > Lock test done. > > Shutting down. > > The system is halted. > > > > real 2.4 > > user 1.5 > > sys 0.1 > > > > @10000Hz ------------------------- > > Starting lock test... > > #lock threads: 100, #loops: 100 > > Lock test done. > > Shutting down. > > The system is halted. > > > > real 132.3 > > user 60.9 > > sys 0.5 > > >

23 years, 3 months

CVS import and merge

by David Holland

A. Student (astudent(a)fas.harvard.edu) wrote: > I'm just starting asst1 now. I downloaded the new v1.00 src tree > from the web site, unpacked it, and did a cvs import. The import > seemed to work fine and then I was presented with a message telling > me that I had 2 conflicts during the import and that I should use > the following command to help the merge: > > cvs checkout -jcs161-staff:yesterday -jcs161-staff src > > I executed the command, but I am unsure of what to do now. How do > I find the conflicts, reconcile them, etc. Here's what you do: 1. Go into a temp directory. Don't do this in your main working directory. (If you did, it will make a bit of a mess and leave cvs in a state where nothing works; doing "cvs co src" from ~/cs161 should recover things.) 2. Do the command cvs said to do: cvs checkout -jcs161-staff:yesterday -jcs161-staff src This will check out an extra temporary copy of the source tree, merging the changes. If it prints C filename for any file, that's a conflict you have to resolve by hand; edit the file and look for the place(s) that has <<<<<<<< your-version ======== our-version >>>>>>>> and decide which version you want (or merge the two). Warning: occasionally you may also need to edit things that are immediately outside the <<< >>> block. (Note: if you get conflicts on depend.mk files, you don't need to edit them by hand - just delete them. They're automatically generated and you can generate new ones later.) Note that when you do this, you may not in fact get any actual conflicts, just some files that come up as modified when you do cvs update. These are changes cvs was able to merge successfully on the second try. 3. When you're satisfied with the conflict resolution you've done, or if you didn't have to do any, do a cvs commit from the top of the temporary copy of the source tree. 4. Now you can (and should) delete the temporary copy. 5. Now go to your regular working copy of the source tree (~/cs161/src) and type "cvs update -d". This will pull the changes into your working tree. -- - David A. Holland | VINO project home page: dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino

23 years, 3 months

Re: cs161-list -- confirmation of subscription -- request 757676

by Jeff DeSoto

On Tue, 6 Feb 2001 cs161-list-request(a)fas.harvard.edu wrote: > cs161-list -- confirmation of subscription -- request 757676 > > We have received a request from 140.247.171.172 for subscription of > your email address, <desoto(a)hcs.harvard.edu>, to the > cs161-list(a)fas.harvard.edu mailing list. To confirm the request, > please send a message to cs161-list-request(a)fas.harvard.edu, and > either: > > - maintain the subject line as is (the reply's additional "Re:" is > ok), > > - or include the following line - and only the following line - in the > message body: > > confirm 757676 > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form.) > > If you do not wish to subscribe to this list, please simply disregard > this message. Send questions to cs161-list-admin(a)fas.harvard.edu. >

23 years, 3 months

Re: cs161-list -- confirmation of subscription -- request 671669

by Chen-Mou Cheng

23 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

cs161-list February 2001