Marquette University logo      

Course Syllabus
Operating Systems (and Networks)
COSC 3250 / COEN 4820 / EECE 5820
Drs. Dennis Brylow (MSCS) and George Corliss (EECE)





Office Hours:

TAs: To Be Announced.

Bulletin description:


Text: Brian Kernighan and Dennis Ritchie, The C Programming Language, second edition. Prentice Hall. We will make our way quickly through The C Programming Language (which is traditionally referred to simply as "K&R" by those in the know) to get up to speed on C programming. The text is a remarkably elegant introduction to what remains the standard language of systems programming, written by the men who designed C and UNIX. See Guide to C Developer Resources.

Electronic versions are available. Shop around.

We will move more slowly through Operating Systems Concepts. It is a large book filled with examples of real-world operating system components; a second, advanced operating systems course would be able to make it the rest of the way through the book. Readings will be regularly assigned from the textbooks. Lectures will assume that students have already read the assigned chapters. In addition, some of the written homework problems may be assigned out of the book. Some of these problems also make excellent exam questions.

We also recommend William Stallings, Operating Systems: Internals & Design Principles, Prentice Hall. URL: Especially, we recommend the "Just Enough C" tutorials there.

English: Correct English grammar, style, usage, and spelling is expected in homework, programming comments, exam solutions, emails, and any other communication. You must write anyway, so why practice writing poorly?

Team teaching: Two courses, COSC 3250 Operating Systems and COEN 4820 Operating Systems and Networks, are being taught in partnership by Dr. Dennis Brylow (MSCS) and Dr. George Corliss (EECE). In principle, Brylow is responsible for COSC 3250, and Corliss is responsible for COEN 4820. In practice, Corliss is responsible for most discussions of material from the text Operating System Concepts and for the construction and grading of examinations. Brylow is responsible for laboratory projects, the material to help you complete them, and their grading.

We are team teaching these classes because this strategy gives you the strongest course for our investment of effort. Besides, if you think there is a meaningful difference between computer science and computer engineering, we intend to mess with your mind by making the "engineer" in the partnership help you learn the "theory," while the "scientist" in the partnership helps you learn the "practice." In short, we do not see a significant difference between "science" and "engineering" in this context, and "theory" and "practice" have no meaning without the other. [Textbook and exams] and [lab and projects] is simply a convenient strategy for us to divide and conquer the material.

"Engineering" vs. "Science": The theory and practice of Computer Operating Systems is indebted to mathematics, computer science, computer engineering, and thousands of clever people. In this course, we use the terms "science" and "engineering" usually as synonyms. We intend neither complement nor insult in our use of either term. We intend both terms to be inclusive. For example, both Brylow and Corliss are members of both the ACM (generally toward the "science" side) and the IEEE (generally toward the "engineering" side). We encourage you to become members of both, too. Student memberships give you access to great professional development resources.

Corollary: "COSC 3250" == "COEN 4820" == "EECE 5820" == "OpSys"

Lab sections: While the lab sections for this three credit course are strictly optional, we have scheduled it based upon insistent feedback in previous years. A regular lab hour guarantees a block of time for project partners to meet and work. Dr. Brylow will use the optional lab block to present tutorials on the course development environment, helpful tools for building and testing systems software, more detailed examples, and insights into the project assignments. In short, we'll make it worth your while. Plan to attend the lab session each week unless you find this course to be too easy.

Course goals: UNION of

COEN 4820: To provide students with an understanding of the standard problems and their solutions in the area of operating systems (including process management, storage management, I/O systems design, distributed systems, protection and security) and with practical experience with one or more modern operating systems (usually some versions of Unix, Windows, Linux, and Mac OSX). See also course objectives by chapter.

COSC 3250: Upon completing this course, students will be able to:

  • Understand the basic concepts of operating system process control, synchronization, and scheduling;
  • Understand the concepts and technologies involved with operating system memory management, secondary storage, and file systems;
  • Design and modify the components of an operating system;
  • Read and write programs in the C language.

Grades: A: [93, 100]; A-: [90, 93); B+: [86, 90); B: [82, 86); B-: [78, 82); C+: [74, 78); C: [70, 74); C-: [66, 70); D+: [62, 66); D: [58, 62); F: [0, 58)

  • 50% Individual projects and homework assignments
  • 10% Participation, measured by daily note cards and occasional quizzes
  • 20% Two midterm exams,
  • 20% Final exam,

There will be no make-up exams. If you are sick, we will make other accommodations.

Late assignments WILL NOT BE ACCEPTED.

In accordance with university policies, graduate students taking this course as EECE 5820 for graduate credit will complete additional work.

Excused from the final? There are several high-quality MOOCS courses being offered on computer operating systems and sub-topics of this course. Some I found are listed here. If you

  1. Request permission from Dr. Corliss before LaterOf(February 19, date MOOCS begins) with
    1. Name of the course you wish to take
    2. Name of offering institution
    3. URL for course description
  2. Receive his approval
  3. Submit to Dr. Corliss by May 3 a certificate of MOOCS course completion
you will be excused from the final examination in this course. More specifically, you will be credited as earning a score of 98 on the final exam. A similar offer may apply if you earn an appropriate professional certificate (approved in advance by Dr. Corliss).

Attendance: The attendance policy in this course is based upon the Marquette University undergraduate attendance policy, which is included in the undergraduate bulletin available at Students are expected to attend all class meetings. Students expecting to miss class as a result of legal obligations or university-sanctioned activities and related travel should notify the instructors prior to the day of the class meeting. Absences will be penalized at the rate of 1% of the final grade per absence beyond four class meetings. According to the University Attendance Policy, "With few exceptions, no distinction is made between excused and unexcused absences." We take that to mean that sickness happens, and job interviews are wonderful uses of your time, but if you are in class, you are in class, and if you are not in class, you are not in class. It is your responsibility to obtain missed lecture material. Assignments are due as scheduled, including days when class does not meet, although we can be understanding when necessary.

Bonus: We may offer opportunities to earn a bonus of 1% of the final grade (up to a maximum of 5%) for attending out-of-class live speakers on topics considered in this class and submitting a brief report. Initial opportunities include:

  • Assist with ACM HS student programming competition
  • You are welcome to suggest in advance speakers you think should be considered.
  • More details will be announced in class, but a brief report emailed to Corliss within a week of the event will earn 1% bonus toward your final grade (with a maximum of 5% available)

The last day of classes, May 3, is Design Day in the College of Engineering. We may make/offer special arrangements in this class.

Class participation. We expect to see

  1. Preparation: the extent of your reading, analyzing and understanding of the material, demonstrated by contribution to discussion.
  2. Contribution to discussion: the extent to which you volunteered answers, asked relevant questions, expressed your own opinions and analyzed the contributions of others.
  3. Group skills: the extent to which you allowed others to contribute, avoided class domination, shared ideas with others, assisted others, provided positive feedback to others and exhibited tolerance and respect for others.
  4. Communication skills: the quality of your expression, clarity, conciseness, use of appropriate vocabulary, confidence. Attendance: includes punctuality.

    From Dancer and Kamvounias, (2005). Student involvement in assessment: A project designed to assess class participation fairly and reliably. Assessment & Evaluation in Higher Education, 30 (4), 445-454.

No, we do not rigorously assess each of those.

Classroom etiquette: In class it is expected you will demonstrate respect for your fellow classmates and your instructors. This is accomplished by:

  1. Being to class on time (on those rare occasions when you may be late, please enter quietly);
  2. Waiting until the speaker (student, instructor, or guest) has completed the lecture before you begin packing up (if it seems the topic is not wrapping up, courteously remind them of the time); and
  3. Turning off audio settings of cell phones, pagers and watches (and any other sound making devices that will have been created since the time of this writing). Simply put, common courtesy, manners and respect is expected.

You should not use any digital device for non-course related activities during lectures (Internet browsing, texting, facebooking, tweeting, instagramming, snap chatting, etc.). These activities prevent you from engaging with the class, and it will distract other students.

"In a September 2012 post, I briefly highlighted a number of studies documenting that most students don't multi-task well. When they're texting, looking at Facebook, or cruising on the Internet and listening to a lecture or discussion and trying to take notes, they aren't dealing with the content as well as they would be if they just focused on listening and note taking. And the evidence of that keeps accumulating, like the Kuznekoff and Titsworth study referenced here and described in detail in the January issue of The Teaching Professor. Using an intriguing study design, here's what they found: ". . . students who use their mobile phones during class lectures tend to write down less information, recall less information, and perform worse on a multiple-choice test than those students who abstain from using their mobile phones during class." (p. 251)." -- From Maryellen Weimer, Getting Students to Put Away Their Phones and Focus on Learning (emphasis added)

Communications: We will rely heavily on electronic communications, and we encourage you to do the same. Homework assignments, hints, and items of interest will be distributed by e-mail and on the class Web site. You should check daily for electronic mail.

Students with Disabilities: Marquette University is committed to providing access and reasonable accommodation in its education for individuals with disabilities. To request disability accommodation in this class, please contact the MU Office of Disability Services, Marquette Hall, Suite 05, 1217 W. Wisconsin Avenue, (414) 288-1645, We will implement all accommodations prescribed by ODS.

Academic Integrity Students are expected to follow the Honor Pledge, which states

  1. I recognize the importance of personal integrity in all aspects of life and work.
  2. I commit myself to truthfulness, honor, and responsibility, by which I earn the respect of others.
  3. I support the development of good character, and commit myself to uphold the highest standards of academic integrity as an important aspect of personal integrity.
  4. My commitment obliges me to conduct myself according to the Marquette University Honor Code.

Please also refer to:

Ethics: Students and faculty are expected to abide by the ACM Code of Ethics and Professional Conduct and the IEEE Code of Conduct.

In this class, some assignments are individual assignments, and for some, you will be assigned into small teams. If the assignment calls for you to work together, the assignments are considered the product of the team.

The University Academic honesty policies and procedures define "Offering another person's work as one's own," as one of eight acts of cheating.

Advice: Each year, we have cases of students copying lab assignment code from Internet sources and/or submitting nearly identical code. Students have been known to copy from the Internet code written by Dr. Brylow to submit to Dr. Brylow. We do not consider that wise, at several levels. We submit your lab assignments to similarity-checking software, so if you cheat, you are likely to get caught. If this is a first offence, the penalty is a zero on the affected assignment and at least the following assignment, extra-close scrutiny for the rest of the term, and your actions are reported to your College and your Department according to the University's policies. The penalty for repeated offences is expulsion from the class and possibly from the University. We have prevented cheaters from graduating. We are serious; we expect you to be serious, too.

If your teammate copies, and you do not know about it, you are subject to the same penalty. Because the assignment was submitted in your name, you also are guilty of "Offering another person's work as one's own," because you were not aware of it.

The University's definition of cheating as "Offering another person's work as one's own," validates the common joke that "It's not cheating if you credit your sources." In this class, if you receive inappropriate assistance from classmates or from the Web AND you credit the sources from which you received the assistance, you will NOT be judged to have cheated. However, you may be judged to have failed to follow instructions, and you may be penalized as much as half the credit you might have otherwise received. Credit the sources you consult and the assistance you receive.

To be clear, suppose it is late before an assignment is due, and yours is not going well. If you copy a perfect solution from a friend or from the web, and if you are detected (likely), you will receive zeros on at least two homework assignments, and your actions are reported. On the other hand, if you include a comment in the header of all affected code files saying where you found the code and what you did to adapt it to the assignment, you will be penalized at most 50% on this assignment.

You are also guilty of "Offering another person's work as one's own" if you do no work on an assignment, your teammate does it all, and your teammate includes your name on the assignment submission. If you do no work on an assignment, we will not file an official finding of cheating against you, but we will reduce your grade on that assignment, perhaps to zero. Don't stiff your teammates.

The risks of plagiarism are too great to justify the possible rewards. Do your own work. You ARE strongly encouraged to discuss that work with your instructors and with appropriate content experts as it proceeds. If you are in doubt about what is appropriate, you should consult with us in advance. In general, you are OK if you have added value to any assistance you receive, provided you make it clear in your reports what assistance you received and its source. See University Academic honesty policies and procedures.

The March 2009 ASEE Prism magazine had a cover article on academic dishonesty in engineering education. It is available online at

No electronic devices (e.g., cell phones) may be used during exams. If we see your phone (or other devices) during an exam, you will be asked to leave the exam immediately. You will receive a grade of zero on that exam.

See University policies:

 -  Academic policies
 -  Academic honesty
 -  Academic attendance

Colloquia: Departments have regular research colloquia to give you a chance to hear from experts. Some talks are advanced research; others are about current practice in industry. Some speakers are former students; some are known around the world; some are both. We strongly encourage you to participate in departmental colloquia, and we will often call your attention to coming events of special notice. Usual colloquium times: MSCS - Thursday 3:30 - 4:30 in Cudahy 401, EECE - Tuesday 2:00 in Engineering 120, BIEN - Friday noon in Olin 202, all subject to change.

Electronic resources: Everyone who accesses or uses Marquette University's electronic resources (as defined in the policy) are bound by the responsibilities and limitations outlined in the Marquette Acceptable Use of Electronic Resources policy. We encourage you to review this policy. In addition, the Opus College of Engineering hosts an intermittent series, "Connecting with the World." Watch for notices.


Advice and Testimonials:

Austin Anderson (Spring 2016)

Found it amusing that Kopp's references their burgers on their receipts via pointers (see attached). Perhaps one might offer to try malloc'ing for one last 1/4 pound burger and see if they can stomach it?


See, OS CAN permanently warp your view of the world -- GC

David Vitale (Spring 2016)

I figured you would appreciate this quick follow up, I finally got this UART issue all signed off on and submitted yesterday. The issue ended up being some bizarre race condition where interrupting a FIFO read of Bay Trail's 16550 UART device could cause one of the Linux serial drivers to not give up the spinlock, resulting in a locked up system.

Not only was I able to discover this issue thanks to your O.S. class (and copious googling), I was able to walk my supervisor through the error using the words "race condition" and "spinlock" 90% correctly. He was pretty impressed. I could not have done any of this without your O.S. class, so once again, thank you.

Side note - the cool thing about working on X-ES's Linux team is how often we attempt to submit patches upstream. If I'm lucky and the powers that be determine my patch to be acceptable, some of my code could make it in the upstream Linux kernel! I'd have eternal bragging rights over my friends.

Zach Barr (Spring 2016)

Just wanted to let you guys know I really enjoyed that Operating Systems class. You expected us to be able to keep up with complicated concepts like a high level class should. It was challenging but no one had a problem staying up late to work on it. Every assignment used a new combination of data structures. Awesome class.

Paul Schmitt (Spring 2014)

Dr. Corliss sent out an email asking previous OS students if they would like to share any advice with you about operating systems. So based on my experience, here's some pro tips to having an awesome, or a least survivable, experience in operating systems.

1. Sign up for a MOOCS course NOW!

If you haven't read your syllabus yet, you should know you can be excused from taking the final if you complete one of the online MOOCS listed here. This deal was there when I took OS. At first, I wasn't planning to take it. Fortunately, I was convinced by a friend, and it was probably the single best decision I ever made with regards to OS. The MOOCS are not difficult. The one I took (this one, which I recommend) I thought was very informative, and I really enjoyed it. I can't recommend to you enough that you take Dr. Corliss's offer. It's a win. You get a 98 on your final (worth 20% of your grade) and can learn more about computers in a very accessible format. You will not regret it.

2. Version control! Version control! Version control! (git commit -m "to memory. forever.")

One of my biggest mistakes/regrets when I took OS was not using version control. Software development is a team sport. When you get a job as a developer, you will not be working in isolation. You will be collaborating and sharing your code with other developers and working on a common code base. To manage these teams effectively, some wise wizards of the software realm created version control, which allows your code and, more importantly, your changes to the code, to be archived and easily shared with other developers. Despite the ease of cowboy coding version control (i.e., copy paste), such strategies for archiving and sharing code will become impractical as the number of developers on project increase and/or the amount of code increases. A version control tool is they way to go for managing your OS code. I recommend using git and setting up either a bitbucket or github repository for your OS team. There will be a little bit of a learning curve, put the payoff for both the short term (this course) and long term (your career) are worth it.

3. Vim? No more!

I imagine that most of you have been using vim to write your C code projects (simply because that's what Dr. D. used when he should you the demos). And if this is your first time using a Linux environment, you may be quite frustrated with trying to get use to vim when you've been use to using crtl-s ,ctrl-c, ctr-v to save, copy, and paste in easy point-click world of Windows. I've got good news for you then. There are other tools that you can use while sshed into morbius (or any of the other boxes) to edit files. If your looking for a simple text editor that's easy, I recommend nano, but my favorite is Eclipse. Eclipse has this wonderful plugin that allows you to code an eclipse project remotely over ssh, but if you want the best experience for developing OS code, I recommend going to the systems lab and using Eclipse. I like Eclipse because when you get the tarball for OS projects, you can easily see all the dependencies, and while you are typing, Eclipse has a code assist feature that lets you easily see what functions are available. Plus Eclipse also has a git plugin.

4. Start Early.

The absolute best advice to succeed in OS is to start early when it comes to doing the assignments. The last thing you want to be doing is up at 4 in the morning it is due and wondering why your code keeps causing segment faults. Specific assignments to watch out for are the context switching and priority scheduling.

5. Master C

Another critical thing to do if you want a good experience in OS and to be just a better programmer in general is to really learn C (remember, "Java programmers understand Java; C programmers understand computers") . I would highly recommend you read the C book (something I did not do while I was taking OS, but I've read it since then) and make sure you understand C's compilation model (this will help you better understand compiler and linker errors). Other really good C concepts to know are pointers and arrays, how to think about them, and how they're related (an array effectively is a constant pointer). Also know about prototype declarations, structs, and keywords (fun fact: static in C does not mean the same as static in Java).

6. Partner Management (OS class: bringing computer scientists and engineers together since forever):

Maybe the most important (just below start early) how you and your team work together. This is often a big source of the frustration in OS, because your assigned a partner. You have no way to gauge the work ethic of who you got paired up. You could have had someone who takes initiative and actively does work on the assignments, or you could have a freeloader. Either way, the situation is close to the real world (expect you and your partner aren't getting paid, getting an F isn't quite the same as being fired, and you probably don't have kids at this time who need to eat food (i.e., your responsibilities are low)). That being said, be sure to have a game plan with how you handle OS projects. Pick a time to might split the assignment into modules, have your partner do some work, you do some other work. You are using version control! So you can just merge work together. If you do not have aforementioned game plan, then collaboration with your teammate might either be non existent (this was my experience) or just a distraction fest.

Alright; I think that's enough advice.
Peace out,

Casey O'Hare (Spring 2015)

I just wanted to mention how amazing it has been having you as a professor this past semester. It's not every day you see professors such as you and Dr. Brylow who have such a passion for what they are teaching, and that goes a long way for students. So thank you, Dr. Corliss and Dr. Brylow.

Art Azarenko (Spring 2012)

It's been a great pleasure for me to be in your class. My knowledge had tremendously increased about detailed functionality of computer components. Your lectures were amazing! Taking the theory in practice, I'm ordering right now server components for virtual laboratory to perform security testing and progress in understanding security field. I will definitely keep in touch through the LinkedIn network, and I hope to see you around Marquette campus!

Tsuginosuke Sakauchi

I was not surprised that you are still teaching the Operating Systems class! That was a challenging class, and contained very important concepts like memory allocation, stack, race conditions, and locks. I continue to deal with many of these concepts daily. Tsugi completed this class several years ago. He now works at Dematic.


  Marquette University. Be The Difference. Marquette | Corliss |