Continue our discussion of nonblocking I/O, discussing its pros and cons while comparing it to blocking I/O approaches relying on multithreading and multiprocessing.
Continue our discussion of nonblocking I/O, discussing its pros and cons while comparing it to blocking I/O approaches relying on multithreading and multiprocessing.
Continue our discussion of nonblocking I/O, discussing its pros and cons while comparing it to blocking I/O approaches relying on multithreading and multiprocessing.
First things first, we'll spend the majority of, if not all of, today's lecture to review and highlight all of the general systems design principles we've been exposed to over the course of the quarter and try to make it clear that a system's design is generally more intellectually captivating than its implementation.
Time permitting, we'll graduate into a surface discussion of a topic that many former students of mine now in the field think belongs in a class like CS110: nonblocking I/O and event-driven programming. We won't get very far with this today, but if I can, I'll clarify what a slow system call is and why syscalls like read, waitpid, and accept are considered slow, whereas syscalls like getpid, close, and even fork and execvp, by my own definition, are not.
We'll take some time reviewing the more nuanced parts of your thread-pool assignment, and then spend a good amount of time understanding networking.
First half: Work through the implementation of createServerSocket, and then work through an architecturally novel server that relies on the services of another executable.
Second half: Work through a quick discussion of how an industrial strength MapReduce implementation might be architected and implemented. Your final assignment—Assignment 8—goes out on Wednesday, and this discussion will help you make immediatel progress on building your very own MapReduce framework.
I need to work through the web-get example I posted last Friday. Once I get through that, you'll be in a position to tackle Assignment 7 (which goes out today).
I need to work through the implementation of a few functions—createClientSocket and createServerSocket in particular—that we've pretended are just built-ins even though they're not. That'll require we understand a collection of Linux system calls that focus on networking directive (or at least understand them enough to understand how createClientSocket and createServerSocket work for us.
I also want to show you how to build a simple API leveraging functionality that's prepackaged in an executable that already exists (and we might not have the source code for). We'll employ our trusty subprocess from Assignment 3 to do so. ya fvor code reuse@ :)
I want to write a few simple networked servers, each one slightly more robust and parallel than the previous one, and then write a few networked client applications. Time permitting, we'll discuss the data structures and system calls Linux provides so that all of this is possible. (If not this time, then next time).
Today we'll formally introduce networking, the client-server idiom, request-response, and argue why a network connection is little more than a bidirectional pipe between processes on different machines.
This week's discussion section is driven by the short answer question. I'm devoting the entire section to compare and constrast the process
We'll spend the first 30 or so minutes covering the collection of myth-busters examples to illustrate why networking and multithreading work together so well. We'll spend the rest of lecture working through one large multithreading example (the Ice Cream Parlor Simulation) designed to illustrate all of the different concurrency patterns that come up in practice.
Today was midterm day, but I still wanted to inline an entry for today's class so that I can present links to the Assignment 5 handout (which was also linked in an announcement posted on Tuesday) and to the Midterm Redux handout as well. The CA's sacrificed their Friday night to grade all of the exams lickety split, and I'll be posting grades to your gradebook by late tomorrow morning, if not sooner.
As with last week, I'm asking the CA's leading the discussions to focus on Problem 1 and to really force you to look at mutexes and condition variables from many different angles. Time permitting, you can all work on Problem 2 as a coding exercise, but realistically I expect you'll all be more interested in asking questions about the impending midterm.
On Friday, we introduced the condition variable to the dining-philosopher program, and by doing so we removed not only the threat of deadlock but also the busy waiting. Today we'll work through the semaphore interface and implementation, fold it into our final dining-philosopher solution and a new reader-writer program, pontificate about what the best initial values are, and then move on to simulate a few networking examples that rely on threading and our concurrency directives to foster thread communication.
Reimplement ticket-agents to get more practice with threads and shared data, initially introduciung a more serious race condition that we saw in confused-extroverts. Introduce the mutex as a data struct with atomic lock and unlock operations, and leverage this mutex idea to ensure that at most one thread can be doing any analysis or surgery on the shared data at any one moment.
Advance on introduce the canonical Dining Philosophers problem, using it as a vehicle to learn even more about threads, race conditions, critical regions, and the mutex, and introduce the concept of deadlock, busy waiting, spin locks, and condition variables.
I've instructed the CA's to focus on Problem 1, which is a cover for many short answer questions designed to exercise your understanding and challenge any misconceptions you have about how each of the programs in Assignment 3 work. In particular, Problem 1 works very hard to confirm that you've internalized every little detail about how sigsuspend, sigsuspend, and ptrace work.
Revisit introverts, implement extroverts two ways, discuss what a race condition is and why they're rarely if ever okay, and then formally transition from C and pthreads to C++ threads.
Review virtual memory, pages, translation lookaside buffers, schedulers, context switches, process control blocks, and ready and blocked PCB queues, all with the intent of helping you understand how multiple processes can operate even with a limited amount of RAM and a small number of CPUs. Move on to introduce multithreading, which permits a single process to imitate multiprocessing techniques by allowing several functions to run at the same time.
I'd like you to spend the 50 minutes studying a parallel implementation of mergesort so you understand its architecture and ultimately believing that it works. Time permitting, I'd like you to work through a collection of short answer questions to solidify your understanding of virtual memory and process scheduling.
I'll quickly review SIGCHLD and SIGCHLD handlers, before advancing on to signal masks, how to temporarily block and unblock signal handlers from executing (and why you'd want to do that), how to programmatically send signals to either yourself or another process, and how it is that multiple processes running at the same time can operate as if they own the CPU and all of virtual memory.
We have some pipe and dup2 material to master today, and we'll do so by working through the design and implementation of the subprocess function we used at the end of Monday.
We'll then talk about signals, signal handlers, and signal masks. All fun stuff. :)
This week we'll investigate the use of fork, execvp, and waitpid to build a command line utility called exargs. We'll then blend some file descriptor and multiprocessing work to better understand how the two work together, and time permitting, we'll work through some short answer questions to prompt you to think more holistically about how fork and multiprocessing work.
The lab handout includes a collection of laptop exercises to elevate your gdb and valgrind acumen as well, though my guess is that the CA who leads your discussion section will opt to focus on the whiteboard problems and leave the laptop experimentation to you.
Today we'll advance our understanding of fork and waitpid (and introduce execvp!) and continue building genuinely useful process control routines. We'll also introduce the notion of a pipe (via the astutely named pipe system call) and illustrate how it works and how it can be used to foster communication between two different processes.
Pipes. Are. Awesome.
Continue our discussion of the system calls that help us create and monitor new processes. The system calls: fork, waitpid, getpid, getppid, and execvp. Additional directives of interest: WIFEXITED and WEXITSTATUS macros.
Your first lab will have you discuss the various ways you can exploit a file system design to implement other functions. You'll also get a chance to play with the stat command line utility and learn some new valgrind tricks.
Finish up filesystems, speak of layering and naming as basic principles of system design, move on to multiprocessing.
We'll work through a few more UNIX Filesystem API examples before advancing on to a discussion of how the raw hardware of a disk is leveraged to look like the filesystem you've taken for granted for the entirety of your UNIX and programming careers. (We've done a little bit of this already, but I want to extend our discussion of how a filesystem is implemented to include directories and symbolic links.) I also want to talk about how human-friendly names like /usr/class/cs110/WWW and /usr/include/stdio.h are parsed by the filesystem to locate the relevant inode.
Good stuff, these filesystems.
We need to invest some time learning about some C and some UNIX/Linux libraries that offer us programmatic access to the file system. There are a few data structures and a collection of Linux library functions that allow us to crawl over the tree of files and directories, and there are even more functions that grant us raw, low-level access to the file contents. We'll invest some time discussing these functions and data structures—enough that we can implement a collection of obvious and not-so-obvious programs that emulate some of the terminal/shell builtins you've been using your entire UNIX lives.
Introductions, course administration and expectations. Standard first day stuff.
The CA's rallied through a twelve-hour grading session yesterday to grade all of your final exams, and grades have been posted to that CS110 Gradebook thingy you know about. SCPD midterms will be sent back either today or tomorrow, depending on when I get down to Stanford next.
The median score was a 42 out of 70, and score ranged from 3 to 62. The 42 will be curved up to an 80%, then 62 will be curved up to a 100%, and everything else will be linearly scaled up in that y = mx + b manner.
I've posted one final CS110 handout right here, but it won't include links to the final exam or the solution until this coming Monday, when one student who, for the best of reasons, needs to take the final. Expect to see final grades posted to Axess by Tuesday evening at the latest, and probably much, much sooner than that.
Thanks for an wonderful quarter, enjoy your summer break, and drop by my office this coming autumn when we're all back in school.
I'll be releasing Assignment 7 and 8 grades within the next few hours, and you can inspect your scores by visiting the infamous CS110 Gradebook. Recall that Assignment 8 was code reviewed, so functionality counts for 100% for that one assignment.
If you need a regrade request, then send an email directly to the CA who graded your assignment. His or her SUNet ID is printed near the top left corner of each grade report.
Thanks, everyone, and good luck tomorrow!
I just released the last of the Assignment 6 grade reports, so feel free to inspect yours by visiting your CS110 Gradebook.
The median score was a perfect 92 out of 92 (and 106 of you pulled that perfect score).
Here's a distrbution of how everyone did:
0-9: ##
30-39: #
40-49: ##
50-59: #
60-69: ###
70-79: ########################
80-89: ###################################
90-99: ################################################################### [--> 127 of these]
I've posted the Assigment 8 handout right here, and all of the assign8 repos will be generated by the time you read this announcement.
Two items you'll want to know before starting:
First off, Assignment 8 has a slightly different late policy in place, and that late policy is summarized at the bottom of this slide.
Second, Assignment 8 will be pressed through our autograding process on Saturday, June 10th, the day after the hard deadline has passed. We'll be sending grade reports back to the vast majority of you as soon as possible, but we will not be doing code reviews. It's more important that you get a complete picture of what your overall assignment average is going in to the final, and that's easier to provide if we punt on code reviews. If you do poorly on Assignment 8, are surprised by the poor functionality grade, and want a full code review, then we'll do one for you.
Hey there, CS110 peeps!
A fellow CS110 student of yours is leading the effort to offer a new SIC in the social good space, and he's interested in hearing from anyone who might have strong opinions about how social good is and is not being properly served by the CS department.
If you have a moment, take a few minutes to fill out the general interest form right here. Your responses will very likely inform what the new student-initiated course focuses on.
I just released the last of the Assignment 5 grade reports, so feel free to inspect yours by visiting your CS110 Gradebook.
The median score was a perfect 82 out of 82 (and 127 out of 199 of you pulled that perfect score). Great, great work everyone!
People were a little more creative in their use of threads and semaphores than they really needed to be, but the average style grade was still pretty close to (and just shy of) a 'solid'.
Here's a distrbution of how everyone did:
0-9: #
30-39: ###############
40-49: #############
50-59: ####
60-69: #######
70-79: ################################
80-82: ########################################################### [127 of these]
I just released the last of the Assignment 4 grade reports, so feel free to inspect yours by visiting your CS110 Gradebook.
The median score was a 152 out of 167, which is ten points higher than last quarter's median—that's awesome. There were 198 submissions, scores ranged from 11 to a perfect 167 (and there were 46 student who landed that perfect score). Very nice job, everyone. I'm particularly stoked to see the median jump up 10 points, because I don't see that happen very often.
Here's a distrbution of how everyone did:
10-19: ######
20-29: #
30-39: #
40-49: ##
60-69: ##
70-79: ###
80-89: ######
90-99: ####
100-109: ########
110-119: ###########
120-129: #################
130-139: ########################
140-149: ############
150-159: ###################################
160-167: ##################################################################
I've gone ahead and posted a solution to the Lab 6 handout we covered in sections yesterday, and that solution handout is right here. As always, the Slides and Handouts page includes links to all past lab handouts and their companion solutions.
I've posted the Assigment 6 handout right here, and all of the assign6 repos have been generated. This is conceptually dense assignment, though there isn't a hugh amount of code to write this time around. You need to implement a ThreadPool class (a constructor, a destructor, and two methods), and the solution thread-pool.cc I have in a secret hiding place is less than 100 lines of code (not counting comments). You also need to implement a second NewsAggregator class that uses two ThreadPools, but provided you managed to get Assignment 5 working and you can easily lift some code out of that and install it into your Assignment 6 NewsAggregator, I promise you that this isn't too bad. Most of your time will be spent implementing ThreadPool and verifying that it's bulletproof.
Stanford Alpha Phi Omega, Zeta Chapter is holding a charity auction on Sunday, May 21st at 7pm. They're donating all proceeds to the LifeMoves, which provides food, shelter, and other services to the Bay Area homeless.
An old student of mine asked if I'd donate, and I decided to donate a dinner out in Palo Alto for 7 other students (the catch? it's dinner with me). In an ideal world, those seven students would be current CS110 peeps, so if you can rally six other friends to bid on my dinner or someone else's item, then by all means head over here and place your bid today.
First things first: If you're a current student of mine, live in Wilbur, and are free to join me and a few other Wilburites for dinner this coming Wednesday night, then drop me an email. I can drive up to four students, though I can arrange for more if some of those who want to go have a car and can drive. (For the hungry non-Wilburites feeling excluded, I'm arranging this because I was unable to attend a faculty dinner there a few weeks ago).
Also, an old CS107 TA emailed me a hip blog article yesterday. It's a good read for anyone who even remotely enjoyed CS107 or is enjoying CS110 so far. If you're curious, click right here.
I've posted the Assigment 5 handout right here, and all of the assign5 repos will be generated as soon as a pair of CA's proofread the handout for typos.
Recognizing that you have a midterm on Friday and you're not likely to even look at this until the weekend, I've crafted your Assignment 5 to be the shortest of the quarter. In past offerings, I've given out one large multithreading assignment, but this time I've split that assignment into two, the first being much less involved than the second.
I've gone ahead and released most of the Assignment 3 grade reports, and you can view yours by tapping your CS110 Gradebook and drilling into your Assignment 3 score.
The median grade was an 88 out of 90 (99 of 206 students pulled a perfect 90, 126 pulled 85 or above), and the average style bucket fell just a wee bit under 'solid' this time. Kudos to everyone on landing such great scores on this assignment.
Here's a distrbution of how everyone did:
10-19: ####
20-29: #######
30-39: ###
40-49: ######
50-59: #####
60-69: #################################
70-79: ########
80-89: #########################################
90: ################################################ [-> 99 of these]
Everyone, I received the following in any email from a Stanford junior affiliated with the Westly Foundation, and I told him I'd pass it along to my CS110 students. Here you go (sounds like an interesting opportunity!):
Those of you interested in CS for Social Good will be interested to read about this. CS+Social Good is hosting its spring quarter mixer tomorrow, May 3rd at 6:00pm. Consider it an opportunity to meet fellow Stanford students interested in social good and get to know them.
Assignment 2 grade reports were emailed out about three minutes ago. I've given this assignment every quarter since I started teaching CS110, and this is hands down the best set of Assignment 2 submissions I've even seen. The median grade was a perfect 66 out of 66, and in fact, 191 out of 211 submissions were functionally perfect, and all but 4 submissions landed a score of 60 or higher. That's excellent, excellent work.
Reminder: you can always check your CS110 Gradebook for a list of all of your assignment and exam scores, and you can drill down into the assignment scores to reread your code reviews.
Fully aware you're all on the edge of your seat in anticipation, I've just gone ahead and posted solutions for this past week's lab and discussion section.
Equally important, today marks the day we formally transition from Slack to Piazza. If you haven't aleady, sign up for the CS110 Piazza Forum by clicking right here, and from this point onward post all questions there.
Slack enthusiasts will be happy to know that the party parroting can go on, as I'll continue to rely on Slack for the light chatty exchanges that it's good for. In particular, I will still pay attention to:
I've posted the Assigment 3 handout right here, and all assign3 repositories were generated less than two minutes ago. This is the longest assignment of the quarter, so you're being given 12 days to complete it. I'll cover everything you need to manage the first three of the four problems by the end of Friday's lecture, and those first three problems should keep you busy until Monday, when I'll finish up the material needed for the fourth and final Assignment 3 program.
Note that the majority of the assignment requires you code in C++ again. The assignment is due on Sunday, April 30th at 11:59pm.
Assignment 1 grade reports were emailed out about three minutes ago. If you didn't received the email and the grade isn't visible in your CS110 Gradebook, then let me know and I'll investigate.
Virtually everyone pulled a perfect functionality score of 56 out of 56, and that was the median score. The CAs spent the latter part of their week code reviewing all submissions and pointing out what was good, what wasn't good, and what was fine even if others may have done it differently. We grade style on a bucket system and issue grades of 'solid', 'minor-problems', and 'major-problems'. The vast majority of buckets issued were 'solid's and 'minor-problem's, although there were a very small number of 'major-problem's.
Long story short: everyone did terrific work on the first assignment. Great job, and I'm looking forward to more great things throughout the rest of the quarter.
Note that you can always check your CS110 Gradebook for a list of all of your assignment and exam scores, and you can drill down into the assignment scores to reread your code reviews.
Hey there, CS110 peeps. Some announcements regarding labs:
I decided I was being a jerk re the laboratory component of the course, so I'm changing a few things going forward. Those changes are:
I just posted the Assigment 2 handout right here, and all assign2 repositories have been generated as well. This is the one CS110 assignment this that requires you code in pure C (virtually everything you need to write is low-level byte manipulation, and C is a good language for that), and it falls due a week from today, on April 19th, just before midnight.
SCPD students!
Direct message jerrycainjr on Slack so I can add you to an SCPD-specific channel. We need to discuss office hours and discussion section, and I'd rather that discussion be open to all of you over the course of an afternoon so all decisions are reached by concensus among those impacted.
Assignment 1 went out today! (Need the handout? it's right here.)
The CS110 CAs were kind enough to improvise some office hours tonight and tomorrow, and you can check that schedule out by visiting the CS110 Office Hours page. We haven't published CS110 office hours for Weeks 2 through Week 10 just yet, but those'll be figured out in the coming days. In general, you can bank on CS110 office hours every Sunday through Thursday night from 6:00 until 10:00pm.
Those of you who want to calmly brush up on your C++ skills can check out some slides I created specifically for CS110 a few years ago. Those slides exist right here.
And if you'd like to, you can peruse some online videos that Wonder CS110 CAs Chase and Audrey recorded last quarter. Each video is about 15 minutes long, and they cover these slides. The videos themselves are online right here:
Today. Is. Lab. Signup. Day. On-campus students should visit Lab Signup and join a section that works for you. We have a number of sections at 1:30pm and 2:30pm, so we're expecting the majority of you to choose one of those. But if one of the other times works better (or is the only one that works), then you're welcome to sign up for one of the later or earlier times.
Please understand that each section has a limited number of spots, and once a section is filled up, it's filled up. This is one of those first-come-first-served situations, so be sure to sign up as soon as possible.
SCPD students: I'll be in touch. I promise I haven't forgotten about you.
If you're here, I assume you're taking (or at least considering) CS110 this quarter. I'm more or less set to fire up on Monday, April 3rd at 1:30pm, and look forward to meeting all of you and having a great quarter together!
Between now and then, do a few things for little ol' me.
That's all from Administration Land. I'm looking forward to meeting each and every one of you and advancing your systems programming game over the course of the next eleven weeks.
