ECE 329 Computer Systems Structures

Fall 2008

In this course students will learn the basics of operating systems, including the creation, management, and scheduling of threads and processes; process communication and synchronization; memory management; file systems; and I/O. Programming assignments connect the theory with practice and enable students to further develop their programming skills.

Syllabus

Schedule

Week	Topic	Assignment
1	introduction / overview (1.1-1.11)
2	C/C++ programming languages and tools	assignment #1 (9/5 F)
3	processes and threads (2.1-2.2)
4	thread synchronization (2.3-2.4)	assignment #2 (9/19 F)
5	scheduling (2.5)
6	memory management (4.1-4.2)	midterm (10/3 F)
7	virtual memory: paging and segmentation (4.3, 4.8)
8	page replacement algorithms (4.4-4.7)	assignment #3 (10/22 W)
9	I/O (5.1-5.9)
10	file systems (6.1-6.4)	assignment #4 (11/7 F)
11	multiprocessor systems (8.1-8.3)
12	Unix / Linux (10.1-10.8)	assignment #5 (11/25 T)
13	[break]
14	Windows / IA-32 (11.1-11.10)	assignment #6 (12/5 F)
15	deadlocks (3.1-3.7)
16		final exam (12/11 Th, 11:30 - 2:00)

Textbook and Resources

• Textbook:  A. S. Tanenbaum, Modern Operating Systems, 3rd edition, Prentice Hall, 2008. 
  Recommended Reading:
  • Maurice J. Bach, The Design of the UNIX Operating System, Prentice Hall, 1990.
  • Mark E. Russinovich and David A. Solomon, Microsoft Windows Internals, Microsoft Press, 2005.
  • Allen B. Downey, The Little Book of Semaphores, 2008.
  • Intel IA-32 architecture manuals
• Software: 
  • Microsoft Visual Studio Service Pack 6 download
  • Visual C++ quick guide
  • The MSDN on-line help contains extremely helpful documentation on the Win32 API and MFC.
  • C library reference
  • Another C library reference (including low-level I/O functions)
  • Rename a VC++ project
• Misc:
  • C++ examples for practicing fundamental concepts

Resources for current students (restricted access, not open to the public)
 

Assignments

To gain practical experience with the principles of the course, you will implement several assignments in C/C++.  As shown in the grading chart, code will be graded on whether it compiles, runs, produces the expected behavior, is well documented, and and is written cleanly.  Your code must compile and run on Visual C++ 6.0 SP6.

To turn in your assignment, send an email to assign@assign.ece.clemson.edu (and cc the instructor and grader) with the subject line "ECE329-1,#n" (without quotes but with the # sign), where 'n' is the assignment number.  You may leave the body of the email blank.  Attach a zip file containing a readme.txt file (listing the names of the files in your project along with a brief description of how to run your code and what output should be expected), and all of the files needed to compile your project (such as *.h, *.c, *.cpp, *.rc, *.dsp, *.dsw; do not include *.ncb, *.opt, *.plg, *.aps, or the res, Debug, or Release directories).  You must send this email from your Clemson account, because the assign server is not smart enough to know who you are if you use another account.  (E.g., do not use @g.clemson.edu)  Be sure that this file is actually attached to the email rather than being automatically included in the body of the email (Eudora, for example, has been known include files inline, but this behavior can be turned off).  Also, be sure to change the extension of your zip file (e.g., change .zip to _zip) so that the server does not block the attachment!!!  We cannot grade what we do not receive.  (Also be sure that you're not hiding extensions for known types; in Windows explorer, uncheck the box "Tools.Folder Options.View.Hide extensions for known file types".)

Assignments:

• Assignment #1 (simulated Unix shell)
  Note:  Normally Unix suspends the background process if it tries to print to stdout.  For simplicity, override this behavior and instead allow background processes to print.  Also, be sure to flush the output whether you're using printf or cout.
  Note:  If you're using cout instead of printf, you need to call cout.flush() or cout << flush or cout << endl to make sure that the buffer flushes, to avoid collisions between the threads.
  Note:  It is okay to hardcode the timezone if you cannot get strftime to give you an abbreviated string.
  Note:  For pi, do not worry about handling number of iterations greater than 2^31
  Sample executable:  hw1_unixshell.exe
   
• Assignment #2 (simulated hard drive)
  Note:  When you format the simulated hard disk, you should set all bytes to zero.  The size of the "disk" is up to you, with 64kB being a reasonable number.
  Note:  You may find the fseek() function helpful.
  Note:  You will need to use CreateSemaphore, and you will not need ReleaseMutex.
  Note:  The member variables are public on purpose.  While this is not good programming practice in general, it serves the purpose of making the simulated hard disk look like a real device with lines that can be set to high or low, thereby forcing the simulated hard disk to run in a separate thread.
  Clarification:  On problem 5 of Chapter 2, the phrasing is ambiguous.  The question should read, "How long will they take to complete ..."  In other words, you should calculate the total time for both process to complete, from the start of the first process to the end of the second process.
  Note:  Be sure to wrap your header file with a header guard:
          #ifndef __SimulatedHardDisk_H__
          #define __SimulatedHardDisk_H__
          .....
          #endif //__SimulatedHardDisk_H__
  Sample executable:  hw2_harddisk.exe
  Future:  Should change name from FormatHardDisk to CreateHardDisk.
   
• Assignment #3 (simulated file system)  Files:  SimulatedHardDisk.h  SimulatedHardDisk.obj
  Note:  It is recommended that you create a struct/class called Inode that handles all the data for an i-node, and a struct/class called InodeList that contains the array of i-nodes.  You can ensure that your data structure in memory is synchronized with the hard disk if you read the hard disk when you mount the device and when the user passes the currently mounted device to mkfs, and if you write every change immediately to the disk.  Then you can simply access the copy in memory rather than reading from the disk every time.
  Note:  You should *not* modify SimulatedHardDisk.h in any way.
  Note:  To implement mkfs, you can either
  • use an old-fashioned FILE* with fwrite, or
  • do not format it at all (just create it), then when you first mount a file system check whether it has been formatted -- if not, then format it then, or
  • temporarily set the device of the SimulatedHardDisk to the one that you are formatting, then write out your superblock and inodes, then set the device back to the current one.  To make this feasible, the new version of SimulatedHardDisk.obj allows SetDevice("") to be called with the empty string.
  Sample executable:  hw3_filesystem.exe
   
• Assignment #4 (written questions only)
   
• Assignment #5 (move and copy files)
  Note:  If the destination file already exists, then mv should just print the error, 'File already exists.'  Similarly, if the destination file already exists, then cp should ask the user whether to overwrite the file.  Both commands should check permissions.
  Sample executable:  hw5_cpmv.exe
   
• Assignment #6 (written questions only)
  
   

Instructor: Stan Birchfield, 207-A Riggs Hall, 656-5912, email:  stb at clemson
Office hours:  2:00-4:00pm, F, or by appointment
Grader: Vidya Murali, 015 Riggs Hall, vmurali at clemson
Lectures: 8:00-9:00am MWF, 223 Riggs Hall