You will write the same simulation for a restaurant you wrote in project 2, but this time in Erlang. As before, the simulation has four parameters: the number of eaters (diners) that wish to enter the restaurant; the number of tables in the restaurant (there can only be as many eaters as there are tables at a time; other eaters must wait for a free table before placing their order); the number of cooks in the kitchen that fill orders; and the capacity of machines in the kitchen used for producing food. And as before our particular restaurant will only have three food items (and thus three machines): a burger, made by machine grill, which takes 500 ms to make; fries, made by machine frier, which take 250ms to make; and a coke, made by machine soda_fountain, which takes 100 ms to make.
The only requirement is that you implement the start/4 function of the simulation module. This function takes the four simulation parameters above and runs the simulation; when it's finished, it prints all of the simulation events out (it just collects them during the simulation), and calls validate:validate to validate the simulation. If the simulation is correct, it will return ok; otherwise it will throw an exception (due to validate failing). You do not have to implement a validator, but you might want to for testing.
We have provided lots of code for you to start with. In particular, we give you general-purpose implementations of a blocking queue, sequence counter, and a semaphore that you can use as you wish. These make use of the server module we went over in class.
We also are giving you three simulation-specific modules. simulation_event is like the SimulationEvent class from the java implementation, but also implements logging of events. In particular, your simulation starts by calling simulation_event:start_logger() which starts a logging process. During the simulation's execution, calls to functions like simulation_event:start_simulation(...) will construct an event which is tracked by the logging process. At the end of the simulation we call simulation_event:print() to print out all of the gathered events, simulation_event:flush() to get a list of all the events (which can be validated), and finally simulation_event:stop_logger() to stop the logging process.
The validate module has a single exported function check() takes a list of events (returned by simulation_event:flush()) and checks them according to the validation rules we prescribed for project 2. As you know, these rules are incomplete. You may wish to alter this file for your own testing, to catch more subtle bugs. For your reference, here is our Validate.java class from the project 2 solution.
Finally, simulation is a skeleton of the simulation. We have provided lots of suggested structure to how you do your implementation. The comments in this file suggest what each function would do, and suggest how you might use some of the general modules we've provided. But you are free to implement things however you like: the only requirement is that you implement the simulation:start() function according to the spec mentioned above.
The skeleton code can be imported into an Eclipse workspace. We have used the Erlide Eclipse plugin to set up the project. You can find detailed instructions about setting up Erlide for the Erlang exercises, though as stated there, we have not been completely successful getting the plug-in to work on the most recent Eclipse. You may way to use Emacs instead.
We have provided a basic framework for testing your submission on a multi-core Linux machine, such as linuxlab. test.erl is an Erlang file that condenses testing down to a single no-arg function call (which simplifies the calling of the erl from the command-line). runp4.sh is a bash script which compiles and runs the Erlang test. These files are in the project4 root directory of the provided files, or can be downloaded directly by the above links.
To test on Linuxlab, you need to get all of the files there. A standard procedure for this would be to Export an archive of the Eclipse project (or to zip up a folder of Erlang source files if not using Eclipse) then use an sftp client such as WinSCP (on Windows) to transfer the files to Linuxlab, and finally, use the "unzip" command to extract the files on Linuxlab, e.g. unzip p4.zip. You will want to extract the files into the same directory which contains the test.erl and runp4.sh files, although directory structure at lower levels does not matter. (For example, it does not matter if Erlang source is in the same directory or beneath project4/src/...). If you send the default p4.zip file to Linuxlab and unzip it, it will create a project4 directory. Just go into that directory and then continue with the following steps. (Obviously you'll have go edit the source files to construct your solution.)
Once files have been extracted, type bash to work in a bash shell. Browse to the directory containing the runp4.sh and test.erl files. The command source runp4.sh will run the provided test, printing all compiler and runtime output. Note that all error output, including uncaught exceptions, is redirected to a file "test.out" in the current directory. After running a test, if this file has non-zero size a message "Test PASSED" is printed. Otherwise, we print "Test FAILED". (Note that this means that if your simulation does nothing, the test will be considered as having passed, which is obviously not correct.)
We recommend modifying the test.erl file to include source for additional tests. You can also modify the bash file to run your own tests - just make sure that you don't break our initial setup, which is precisely the setup we'll use to grade your projects. Of course we'll be dropping in our own validate module!Every file you submit should have your name and UID as well as (optionally) the name and UID of a partner. Each student should make his or her own individual submission, and only similarity with your partner's submission will be excused. Submit all files you have. However, you should not change the server.erl or simulation_event.erl files, as we will overwrite these files with our own versions during testing. Also, as mentioned, we will overwrite the validate.erl file with our own, so that if you change it, make sure your simulation still works properly with the old file. All other files can be changed as you wish (and you do not need to use any of them).
Submit your code on the Department's Submit Server. Contact the TA if you have any troubles submitting.
You are also required to submit a short "design document" describing the design choices you made in your simulation. Also describe how you tested your simulation. You may also include any tests that you've written and instructions on how to run these tests.