Homework #5

Assigned: October 13
Due: October 28, 2:00pm


(80 points) A barrier is a common synchronization construct that can be used by cooperating processes or threads to block until all reach a particular point (e.g., in a concurrent implementation of mergesort or matrix multiplication). In this homework, you will build a client-server application in Go to explore the use of named pipes (i.e., FIFOs) in Linux as the communication and synchronization mechanism for a barrier. You may have built a barrier in a prior (OS) course using semaphores, channels, or a monitor; this homework explores a different approach and adds named pipes to your concurrent programming toolkit.


This system involves a barrier server and client desrcribed as follows:

  • Server:
    • The barrier server must be named barrierserver.go.
    • The executable for the barrier server must take two command line arguments: the name of the barrier (name) and the size of the barrier (size), which is the number of client processes which must reach and block at the barrier before any can pass. The server creates a named pipe name.request to receive requests from each client to use the barrier and a named pipe name.release for communicating back to the client that it is okay to proceed by writing release bytes (e.g., if os.Args[1] is barrier, as ./barrierserver barrier 3, the server creates the pipes named barrier.request and barrier.release using syscall.Mkfifo, which uses the same conventions as the analoguous system call in C).
    • The server runs forever, and does the following, in an infinite loop (e.g., for true): open name.request for reading only, read exactly size bytes from name.request one byte at a time, close name.request, open name.release for writing only, write exactly size bytes to name.release (in one stroke), and close name.release.
    • Requires approximately 120 lines of code.
  • Client(s):
    • Use barrierclient.go as a client.
    • Define the function Waitatbarrier(name string, i int, bid int ) error in waitatbarrier.go
    • This function blocks the calling process at the barrier represented by the named pipe with name name. If sucessful this function must return nil; otherwise return an error.
    • The Waitatbarrier function does the following: open name.request for writing only, write exactly one byte to name.request, close name.request, open name.release for reading only, read exactly one byte from name.release, and close name.release.
    • The Waitatbarrier function requires approximately 80 lines of code.
    • How synchronization is acheived for free through I/O on the pipes: The Waitatbarrier function works because of the way blocking is done when a Linux pipe is opened. Recall from lecture that opening a pipe for reading (automatically) blocks until at least one process has the pipe open for writing. Similarly, opening a pipe for writing blocks the calling process until at least one process has it open for reading. A client will block on opening the request pipe until the server has opened it. It will then block on the open of the release pipe until the server has read the bytes of all of the other processes and opened the release pipe for writing. A second attempt to use the barrier with the same name will block on the open of the request pipe until all of the processes have passed the first barrier since the server has closed the request pipe.
    • To get this synchronization for free you must use the Open and Close, and Read and Write system calls in the syscall package, not the Open and Close, and Read and Write library calls in the os package because the library calls do not block, but rather return immediately. Also, notice that the Read and Write system calls only accept Linux file descriptors, not file pointers (as do the library calls), as arguments.
  • Application: Use the runpgm Korn shell script discussed in class to control your client-server application. This will make starting the server and clients, and testing, easier.
  • Format your output statements to os.Stderr exactly as shown in the transcript given here.
  • Check, handle, and reutrn all errors.
  • Use the directory structure depicted in the following diagram for this project:

How to submit

Note: All directory and filenames below are case-sensitive. You must use the directory and filenames exactly as shown below (i.e., all lower case).

Include a README file in the hw4 answering the following questions: What keeps the server running, even after all of the client processes have terminated? Is it possible for a malicous client to bring the server down?

When you structure your project directory as shown above simply tar the hw5 directory as follows: tar cvf hw5.tar hw5/. This will make it easy both for you to submit and us to grade because your submission will already contain the source code files supplied to you.

Only the file /home/<logname>/homeworks/hw5/hw5.tar will be electronically collected from your account on the deadline.

Failure to follow these submission requirements will result in a 10% penalty.


Ninety percent of your score will come from the correctness of your system, and 10% of your score will come from following our programming style guide. Applicable submission penalties will then be applied.

Return Home