Consider an interesting and challenging synchronization problem, the campaign mailer's problem. Suppose that a campaign mailing requires three items: an envelope, a campaign flyer and a stamp. There are three volunteers, each of whom has only one of these items with infinite supply. There is an agent who has an infinite supply of all three items. To put together a mailing, the volunteer who has an envelope must have the other two items, a campaign flyer and a stamp. (You can figure out what happens with the volunteers who start with campaign flyers and stamps, respectively.) The agent and volunteers share a table. The agent randomly generates two items and notifies the volunteer who needs these two items. Once they are taken from the table, the agent supplies another two. On the other hand, each volunteer waits for the agents notification. Once notified, the volunteer picks up the items, puts together a mailing, takes the mailing to the mailbox, and goes back to the table waiting for his next items. The problem is to come up with an algorithm for the volunteers using semaphores as synchronization primitives.

Now, all jokes aside, this is an actual problem related to computer science. The agent represents an operating system that allocates resources, while the volunteers represent applications that need resources. The problem is to make sure that if resources are available that would allow one or more applications to proceed, those applications should be awakened. Conversely, we want to avoid waking an application if it cannot proceed.

A restriction of the problem is that you are not allowed to modify the agent code. (Indeed, if the agent represents an operating system it makes sense to assume that you don't want to modify it every time a new application comes along.) The agent uses these binary semaphores and actually consists of three concurrent threads (one of which is given below.) Each waits on agentSem. Each time its signaled, one agent thread wakes up and provides items by signaling two other semaphores.

Semaphore agentSem = 1;
Semaphore envelope = 0;
Semaphore flyer = 0;
Semaphore stamp = 0;
while (true)
{
Wait(agentSem);
Signal(envelope);
Signal(flyer);
}

(One thing you will need to change when you implement this is to make the three agent threads sleep for a random period of time - up to 200 milliseconds before beginning to wait on agentSem. This will hopefully mix things up and make this more interesting.)

This becomes a hard problem because you can show that the natural solution leads to deadlock. To get around this, propose the use of three additional "pusher" threads that respond to the signals from the agents, keep track of the available items and signal the appropriate volunteer. We first need three Boolean variables to indicate whether or not an item is on the table, three new semaphores to signal the volunteers, and a semaphore for preserving mutual exclusion (as given below.)

Boolean isEnvelope = false;
Boolean isFlyer = false;
Boolean isStamp = false;
Semaphore envelopeSem = 0;
Semaphore flyerSem = 0;
Semaphore stampSem = 0;
Semaphore mutex = 1

Pseudo code for one of the pushers (the one who wakes up when there's an envelope on the table) appears below. If this pusher finds flyer, it knows that the flyer pusher has already run, so it can signal the volunteer with stamps. Similarly, if it finds stamps, the volunteer with flyers is signaled. Finally, if this is the first pusher to run, it cannot signal any volunteer, so sets isEnvelope.

while (true)
{
wait(envelope);
wait(mutex);
if (isFlyer)
{
isFlyer = false;
signal(stampSem);
}
else
if (isStamp)
{
isStamp = false;
signal(flyerSem);
}
else
isEnvelope = true;
signal(mutex);
}

The other pushers are similar. Since they do all the work, the volunteer code is trivial. Pseudo code for the volunteer with an envelope appears below; the others are similar. As above simulate the putting together a mailer and taking the mailing to the mailbox by having the thread sleep for a short period of time (up to 50 milliseconds for both the putting together a mailer and taking the mailing to the mailbox).

while (true)
{
wait(envelopeSem);
Put together a mailer.
signal(agentSem);
Take the mailer to the mailbox.
}

Your solution to the problem is to create a simulation of this problem using Java threads. Create three agent threads, three pushers and six volunteers (two holding envelopes, two flyers, two stamps). Each volunteer finishes three campaign mailings before exiting. (They said something about being hungry as they left.) As such, rather than loop forever, each agent loops six times, and each pusher twelve times. (Think about it.) Remember to join all threads before your program terminates.

Design

1. Write the code for the threads as described in the overview above.

2. Create a driver class and make the name of the driver class Assignment2 containing only one method:

public static void main(String args[]).

The main method itself is fairly short containing code to do the following:

a. Create the number of instances of each thread as described in the overview above.

b. Start each instance of the threads created in a above.

c. The main method needs to keep track of the threads and take care of each thread before it can end. The methods of the Thread class you'll need for this are join() and isAlive(). If the thread is dead then execute a join on it in order to properly dispose of that thread. If the thread is still alive then move on to the next thread. The main method keeps doing this check until the last remaining thread has died and been properly disposed.

3. For the program output, have the agent and volunteer threads produce output. For an agent thread, have it print out the two items it put on the table. For example, the agent thread on page one would print, "The agent has put an envelope and a flyer on the table." For a volunteer thread, have it print out two messages. The first message states that the volunteer put together a mailer and the second message states that the volunteer took the mailer to the mailbox. Each message for the volunteer would be printed at the appropriate time during its execution. For example, the volunteer thread on page three would print The volunteer with envelopes picked up a flyer and stamp from the table and put together a mailer as the first message and The volunteer with envelopes took the mailer to the mailbox as the second message.

4. Semaphores are explicitly implemented with the java.util.concurrent.Semaphore class. The only methods you need and can use from the Semaphore class are: the constructor - Semaphore(int permits, boolean fair), acquire(), and release(). In the constructor for a Semaphore object, the first parameter specifies the initial value (number of permits) for the semaphore and the second parameter states the fairness setting (true or false) for the threads waiting to acquire a permit for the semaphore. For all the semaphores in your program, you will make the fairness setting true because the waiting threads are handled in a First Come First Serve order. The acquire method is the equivalent of the wait method, and the release method is the equivalent of the signal method, as discussed in class.

5. You must declare public each class you create which means you define each class in its own file.

6. You must declare private the data members in every class you create.

7. You can use "implements Runnable" or extends Thread to implement the classes defining the threads in this assignment. You can't use extends in this assignment in defining any class except if you are using extends Thread to define a thread class.

8. Tip: Make your program as modular as possible, not placing all your code in one .java file. You can create as many classes as you need in addition to the classes described above. Methods being reasonably small follow the guidance that "A function does one thing, and does it well." You will lose a lot of points for code readability if you don't make your program as modular as possible. But, do not go overboard on creating classes and methods. Your common sense guides your creation of classes and methods.

9. Do NOT use your own packages in your program. If you see the keyword package on the top line of any of your .java files then you created a package. Create every .java file in the src folder of your Eclipse project, if you're using Eclipse.

10. Do NOT use any graphical user interface code in your program!

11. Do NOT type any comments in your program. If you do a good job of programming by following the advice in number 8 above then it will be easy for me to determine the task of your code.

Academic Honesty!
It is not our intention to break the school's academic policy. Posted solutions are meant to be used as a reference and should not be submitted as is. We are not held liable for any misuse of the solutions. Please see the frequently asked questions page for further questions and inquiries.
Kindly complete the form. Please provide a valid email address and we will get back to you within 24 hours. Payment is through PayPal, Buy me a Coffee or Cryptocurrency. We are a nonprofit organization however we need funds to keep this organization operating and to be able to complete our research and development projects.