Walking Robot: A

(Latest Revision: 11/10/2000)

Concurrent Walking Robot Program: Part A

There is a long hall for robots to use to get from one building to another. It runs north-south. Robots can walk from one end of the hall to the other, but the hall is only wide enough for one robot. There is not enough room for robots to pass each other in the hall. Robots cannot back up or jump over one another.

THE STARTER-PROGRAM:

I am giving you a program called robotShell.cpp. This program runs on the SUN Ultra's. You can compile it with this command:

g++ robotShell.cpp sem.cpp -lpthread -lposix4

When you compile and execute robotShell.cpp, a mother thread spawns 25 child threads (robots) that are randomly assigned either to walk the hall from south to north or from north to south. Each robot simply executes a function that simulates an attempt by the robot to walk the hall as assigned. Each time it successfully walks through the hall, the robot (magically) returns to its starting point without passing back through the hall, and just begins another attempt to cross the hall.

RobotShell.cpp employs some semaphores and does some synchronization. The hall is divided into 16 cells. At most one robot is allowed to occupy a cell at any given time. Each cell is protected by a semaphore.

By appropriate use of the semaphores guarding the cells, robotShell.cpp makes sure that robots cannot collide.

Unfortunately robotShell.cpp does nothing to prevent robots from entering the hall at opposite ends at the same time. Thus if you run robotShell.cpp it deadlocks before long, with robots facing each other in the middle of the hall, unable to get past one another.

YOUR ASSIGNMENT:

Without taking any of its current functionality away, you must add code to robotShell.cpp that makes it satisfy the following requirements:

A Mutual Exclusion Requirement:
- It must be impossible for robots to get into the hall facing each other (because if that happens, they will deadlock).
A Progress Requirement:
- Whenever there are no robots currently traveling south in the hallway, all robots that want to enter and go north through the hallway are eligible to do so without delay. Conversely, whenever there are no robots currently traveling north in the hallway, all robots that want to enter and go south through the hallway are eligible to do so without delay.
  
  Only certain robots may particpate in the decision as to which robot will enter the hallway next:
  - Robots that are curently ready and willing to enter the hall, and
  - Robots that are currently exiting the hall.
  Also, this decision cannot be postponed indefinitely.
  
  Note: The progress requirement implies, for one thing, that no thread may take on the role of a "coordinator" of the other threads.

The code you add to robotShell.cpp has to go into specific places in the program. You are supposed to change only the behaviour of robots that are entering or exiting the hallway. Therefore you will do very little else besides add code to the bodies of the functions "CheckInToHall" and "CheckOutOfHall." These functions are the entry and exit code for the critical section.

Of course, you will also undoubtedly need to add variable declarations at the top of the program, and you will have to add initializations to the init() function.

You should not need to make any other kinds of changes to robotShell.cpp, except to add delay code as needed for testing.

SYNCHRONIZATION AND DELAY TOOLS:

As explained while you were working on your "warm up" assignment -- the concurrent bubble sort -- you must use the pthread_mutex_t stdoutLock to lock stdout for printing messages to the screen.

Other than that one exception you must implement all the thread synchronization in your program by using the sim_semaphore data types that I have implemented for your use in the files sem.h and sem.cpp. As you know, these sim_semaphore's behave exactly like the "counting semaphores" described in Silberschatz and Galvin. Additionally the "list" attached to a sim_semaphore is managed as a FIFO queue. This makes it easier to satisfy bounded waiting requirements when using sim_semaphore's.

You are not allowed to use any "busy-waiting" methods to achieve synchronization.

If you must, you may use some "busy-waiting" loops for delay-code only. (Delay-code is code whose sole purpose is to slow threads down.) I want to discourage the use of busy-waiting, and I doubt that any will be necessary.

For delay-code you should try to get along by using calls to the delayAsMuchAs() function. DelayAsMuchAs() is a function in the robotShell.cpp program. It uses the sched_yield command to do delays. The effect of sched_yield is to send a hint to the scheduler that it may be a good time now to put a different thread in the CPU.

Ask me if you want some help selecting or placing your delay-code. Also I'll be glad to review the design of your program sometime before the due date. However, I will expect that you present the design to me in a clear and understandable form.

WHAT TO TURN IN:

Send me your filled-in version of robotShell.cpp before midnight on the due date, but be sure to
use the subject line: CS3750,prog2.A.
Do not send me a copy of sem.h or sem.cpp -- I'll use my own.
Note that there are no spaces in the subject line given above. It is important that you do not insert any spaces. My e-mail address is: john@ishi.csustan.edu.
Additionally please follow these e-mail rules.

DUE DATE:

For the program due date, see the class schedule.