CS 214 Systems Programming Spring 2015


Brian Russell morbius@cs.rutgers.edu    Office Hours: Wednesdays 8:00-9:00pm, Hill 403.

Teaching Assistants:

Konstantinos Nikolakakis nikolakakis.konstantinos@gmail.com    Office Hours: Mondays 10:00-11:00am, Hill 402

Cheng Li chenglii@cs.rutgers.edu    Office Hours: Tuesdays 9:00-10:00am, Hill 363

Samani Gikandi sgg45@cs.rutgers.edu    Office Hours: Thursdays 1:30-2:30pm, Hill 250


Tim Yong ty114@scarletmail.rutgers.edu    Office Hours: Tuesdays and Thursdays 3:00-5:00 pm Hill 252

Paul Tai pjt64@scarletmail.rutgers.edu    Office Hours: Thursdays 6:00-8:00 pm Hill 252

Katie Poskaitis katiepru@rutgers.edu    Office Hours: Wednesdays 3:00-5:00 pm Hill 252

Eric Bronner eric.bronner@rutgers.edu    Office Hours: Mondays 5:00-7:00 pm, Tuesdays 7:00-9:00 pm Hill 252


The aim of CS214 is to introduce the student to the process of writing low-level programs that interact directly with a computer's operating system and hardware, as well as to develop the student's ability to build large applications in a team environment. Upon completion of this course, the successful student should be able to design, write, test, and analyze moderately complicated programs using the C programming language and UNIX/Linux operating systems.

Prerequisite Knowledge


The following text is used in this course:

Computer Systems - A Programmer's Perspective Second Edition
Randal Bryant and David O"Halloran

The following texts are available online, free of charge.

The textbooks do not cover all material discussed in class, and are not a substitute for attending lectures.

Topics Covered in CS214

The following list is organized by topic, not by chronological order of coverage in the course.

  1. Programming in C

  2. Programming under UNIX

  3. Large-scale development

  4. Concurrent programming

  5. (optional) Embedded systems programming

Lecture Schedule

Jan 20 Into to C, object files, linking and processes

Jan 22 C program structure, C functions, formatted I/O

Jan 27 Finite State Machines and PA1, C preprocessor

Jan 29 Dynamic memory management

Feb 03 Data Structure design

Feb 05 File I/O

Feb 10 multi-file projects, makefiles, directory I/O

Feb 12 gdb -- Bryant and O'Halloran pp 254-256, Valgrind and memory-related bugs

Feb 17 libraries (system-provided, static, dynamic) -- Bryant and O'Halloran pp 681-683

Feb 19 Signals and event-based programming -- Bryant and O'Halloran pp 736-758

Feb 24 Signals and processes

Feb 26 Linux Commands

Mar 03 Multiprogramming -- Bryant and O'Halloran pp 718-736

Mar 05 Threads -- Bryant and O'Halloran pp 947-989

Mar 10 Thread synchronization (mutex locks, semaphores)

Mar 12 Thread synchronization (condition variables), thread patterns

Mar 17 Spring Break - Party.

Mar 19 Spring Break - Go to STD clinic.

Mar 24 Thread patterns (producer-consumer, etc)

Mar 26 Signals and threads

Mar 31 midterm

Apr 02 shared memory

Apr 07 shared memory

Apr 09 malloc() internals -- Bryant and O'Halloran pp 814-836

Apr 14 malloc() internals

Apr 16 Bash shell scripting

Apr 21 Bash shell scripting

Apr 23 shell scripting

Apr 28 UNIX/Linux commands, BASH shell

Apr 28 TBA

This schedule may change as needed.

Interesting Programs

Here's the signal0.c file.

Here's the signal1.c file that prints blocked signals.

Here's the signal2.c file that responds to changes in window size.

Here's the timer1.c file that implements a timer.

Here's the thread1.c file that implements a (really) simple multithreaded application.

Here's the thread3.c file that implements some mutex protection in a multithreaded application.

Here are some dining philosophers programs diners1.c and diners2.c.

Here are some producer/consumer programs prod_consum.c and prod_consum2.c and even one with semaphores and better dynamic memory management prod_consum3.c.

Some Notes

Here are the notes for POSIX multithreading primitives.

And the notes for POSIX mutual exclusion locks.

And the notes for POSIX condition variables.

And some notes for POSIX using mutexes and condition variables in shared memory.

And a toy program that sets up shared memory.

Expected Work

Students are expected to attend all lectures and perform all reading assignments prior to lecture. Students are also expected to attend all recitation section meetings. Students will be evaluated according to their performance on a semester long programming project, a mid-term examination, and a final examination.


WARNING: This is a project course, which means that this course should give you more than a passing knowledge of what writing working programs entails. The project will be a major undertaking. If you complete the programs, you will have learned a lot. However, assess your commitment to this course realistically. If you don't have the time or the inclination to work hard on the project, you would be better off not taking the course. You will have to learn how to build and debug reasonably sized C programs and make them robust to outside errors. You will also have to describe how your program work in a written document.

This one large project will be assigned, as three sub-projects. Up to 2 students can work as a group for each sub-project and you can change group members for each project . Students are required to complete the parts by the scheduled deadlines. Failure to turn in the project by the deadline using the electronic handin website will result in a zero for all team members. No exceptions!

There are many different operating systems and variants of C out there and we cannot test your program on all of them. So all program assignments must run on the local iLab Linux machines. We will be grading your assignments on those machines as well.

Working Together and Academic Honesty

Cheating on projects and exams will not be tolerated. We want to protect the fairness and integrity of the class, so we run code similarity detectors on the projects and scrutinize exams for copying. Both parties in the exchange are liable; e.g. if you give away solutions to friends, you're putting yourself at risk too. If you get caught, it's a nasty process--- just don't go there! You're better off asking for help, or at worst, dropping the course and trying it again. The department academic integrity policy can be found at http://www.cs.rutgers.edu/policies/academicintegrity/. You now need to click explicitly on a link when first login to our computing facilities, use handin, etc., that says you acknowledge being aware of the policy (which you can read through the login screen). If you fail to do the click-through by the end of September, your access to our facilities will cease October 1.


  • Midterm: 20 %

  • Final: 30 %

  • Project: 50%

    The programming part of the projects are typically graded on how close they are to the functional requirements. The written portion is graded on how well the TAs can figure out how your project is constructed only from the written description. Exams are typically graded on a curve. As a rule of thumb, the mean is a "C'" and each standard deviation is one letter grade. This rule can be altered, however, if the class does exceptionally well or poorly.

    I felt we should do our best to clarify up front how we grade your programming assignments. The TAs do the grading, but have all agreed to the same criteria for grading each programming assignment. Each programming assignment is worth 100 points. Here are our grading criteria:

    80% A combination of the following factors:

    - Correctness -- based on number of test cases

    - Algorithmic quality

    - Reusability/Modularity

    - Decomposition

    20% Documentation

    - 10% Test Cases from Students

    - 10% Comments and Documentation (Analysis, readme files, etc...)

    The Gilligan's Island Rule

    We do encourage you to talk to your classmates, provided you follow the Gilligan's Island Rule. After a joint discussion of an assignment or problem, each student should discard all written material and then go do something mind-numbing for half an hour. For example, go watch an episode of Gilligan's Island (or jersey Shore in modern terms), and then recreate the solutions. The idea of this policy is to ensure that you fully understand the solutions or ideas that the group came up with. If you follow the Gilligan's island rule, often best route to follow to get a question answered is to ask, in order: 1. A classmate smarter than you. 2. Your TA. 3. The professor.