Complete one final example that combines nonblocking I/O with event-driven programming techniques as provided by the epoll suite of functions.
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.
The primary focus on Lab 07 is to work through some nuanced post-mortem questions about Assignmnet 7 and the networking portion of the course, and then let you code up a custom MapReduce job as per your Assignment 8 guidelines so you're familiar with what you'll be coding to for your final assignment.
Finish up material from last time that I didn't quite get to. Then, continue on with a 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 rely on the majority (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 spend 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 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 the Wednesday after we get back, and this discussion will help you make immediate progress on building your very own MapReduce framework.
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@ :)
This week, I'll ask that you work through a series of very high-level questions that compare and contrast processes and threads. I also want to confirm you have a clear understanding of why race conditions are race conditions, how to limit the number of threads that are running at any one moment, and how to realize all sorts of interthread communication patterns.
Time permtting, I'll ask that you and your section leader tackle some short case studies that give you some more practice with the conditional_variable_any, which you probably didn't use for Assignment 5, but will almost certainly want to use on Assignment 6.
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).
After a bit of multithreading wrapup, we'll move on to 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.
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.
Last Wednesday, 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.
I've instructed the CA's to focus on Problem 1, which itself is 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.
Problem 2 asks that you use multithreading to introduce parallism into the implementation of quicksort.
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.
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'll discuss 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. :)
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.
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 have graded all of your final exams, and grades have been posted to that CS110 Gradebook thingy you know about. SCPD finals will be sent back either Monday or Tuesday, depending on when I get down to Stanford next.
The median score was a 53 out of 70, and score ranged from 19 to 68. The 53 will be curved up to an 80%, then 68 will be mudged 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. 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 autumn break, and drop by my office this coming January when we're all back.
I've gone ahead and posted the mock final exam being administered tonight at 7:00pm in Dinkelspiel Auditorium, and that mock final exam has been posted right here.
Once you've worked through the mock final, check out the solution handout.
Assignment 7 submissions have been graded, and you can get the good word on how you did by visiting the most reliable source on grades: the CS110 Gradebook. Median grade: 125 out of 125 (with 96 of 173 of you landing perfect scores). Very nice work, everyone!
Here's the distribution of functionality grades:
0-9: #
70-79: ###
90-99: ###########
100-109: ##################
110-119: ########################################
120-125: ########################################################### [ --> 98 of these ]
A former CS110 student of mine sent me an email with information about an event later today. That email is inlined below (with minor edits to reflect the fact that I'm posting it today even though it was sent to me yesterday).
As the co-chair of the Professional Development team for Women in CS, I am organizing an event, part info session and part panel, about International Summer Engineering Opportunities.
The first part of the event will be an info session ran by staff from the Bechtel International Center about fellowships/scholarships for going abroad and about Stanford's Global Engineering Programs. The second part will be a panel with students who have spent their summer abroad pursuing CS research in Switzerland, engineering for social good in Uganda, and a Google internship in London.
This event will take place today, December 7th, from 5:30-6:30pm, in the Assembly Room at the Bechtel International Center, and as is tradition for CS events, food will be provided.
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 93 out of 175 students got all the points. Woo.)
Here's a distrbution of how everyone did:
50- 59: ###
60- 69: #####
70- 79: ##############
80- 89: ############################################################
90- 99: ############################################################### [---> 93 of these]
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 110 out of 176 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 a 'solid'.
Here's a distrbution of how everyone did:
20-29: #
30-39: ####
40-49: #
50-59: #####
60-69: ########
70-79: ###############################################
80-82: ################################################################ [110 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 142 out of 167, and scores ranged from 12 up to a perfect 167 (and there were 14 of those). 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: #############
100-109: #
110-119: ##########
120-129: ########
130-139: ########################
140-149: #################
150-159: ###############################
160-169: ############################################
The CA's rallied through a twelve-hour grading session yesterday to grade thre majority of CS110 midterms, and grades have been posted to that CS110 Gradebook thingy you know about. SCPD midterms will be given back to SCPD by Monday at 5pm, and you should receive a scanned copy of your midterm by Tuesday or Wednesday. (Note: some SCPD midterms sent back to me on Friday evening won't be graded until Monday, so don't be alarmed if you don't see your score just yet).
The median score was a 17 out of 30, and score ranged from 1 to a perfect 30. The 17 will be curved up to an 80%, the 30 will be curved up to a 100%, and everything else will be linearly scaled up in that y = mx + b manner. I've gone ahead and posted a full midterm redux handout right here.
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 90 out of 90 (107 of 184 students pulled a perfect 90, 135 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. (In particular, the class performance this quarter was statistically higher than last spring's, when the class median was an 88 out of 90. That's pretty awesome work, everyone!)
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: ################################################ [-> 107 of these]
Assignment 2 grade reports were emailed out about three minutes ago. The median grade was a perfect 66 out of 66, and in fact, 157 out of 185 submissions were functionally perfect, and all but 11 submissions landed a score of 60 or higher. That's splendid 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.
Fellow CS110 student Belce Doğre asked me to identify an opportunity for those of you eager to devote your software development skills to a social good project. CS51 and CS52 comprise a two-quarter sequence that helps small teams conceive of, research, and implement some application or platform to improve health care, education, government accountability, access to food and clean water, and other domains that improve the lives of others. Those wishing to enroll in CS51 and CS52 are invited to an information session being held on Monday, October 16th at 7:00pm to learn more.
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 better part of their weekend 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.
CS110 is all about its alumni, and I have one more who was recently in touch.
Akshay Rakaswamy and his friend Chetan Rane recently built an application called SchedFriend, which is a tool that students can use to find friends taking the same classes (e.g. CS110) and discover people who share mutual interests (e.g. bowling). Akshay's even put together a a video outlining how you might use the tool to find fellow CS110 students who're up for midnight bowling after you've all submitted Assignment 1 this Wednesday.
We're looking for programming enthusiasts to represent Stanford at the ACM Regional Collegiate Programming Contest, where schools from the Pacific Northwest compete to advance on to the World Finals, this year in Beijing.
The outcomes of a local programming contest, held a week from today and detailed right here dictate who competes as part of a Stanford team. Feel free to reach out to me or Joshua Wang if you have any questions.
Former CS110 student Vicki Nui was in touch and asked if I could share the following:
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, September 25th 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.
