Updates:
For this project, you (and optionally, a partner) will implement a thread-safe logging framework in Java. Consider the general domain of multi-threaded applications in which interesting events occur in multiple threads (e.g. a web/file server, a divide-and-conquer algorithm where different parts are done in different threads, etc.). Reliable logging is necessary, especially when debugging and troubleshooting such applications. Deadlock and race conditions could lead to missing information, information out of order, or even a halt in the logging process, all of which would defeat the purpose of having a log!
The logging framework will exist as a set of classes (templates provided below) that can be combined to address specific logging scenarios. You will design, implement, and test each class, ensuring that your framework is thread-safe under any possible configuration. However, you should take care not to negatively impact performance by "over-synchronizing" or "under-synchronizing" your classes. We provide descriptions of each class and its methods, but the design and testing have been left largely to your discretion.
Your implementation should abide by the following requirements. Violation of any requirement will lead to a deduction of points. More information on the specific behavior of each class is provided in the accompanying javadoc-generated API Specification.
Begin by downloading the project zip file here: Skeleton Code
The directory structure of the zipped folder should allow the existing code to be directly imported into the Eclipse IDE. Note that all code is part of the cmsc433.p1 package, and you should preserve this package structure even if not using an IDE. The provided folder contains the following code in the src directory:
Interfaces (not to be changed):
Skeleton Classes (to be fully implemented; * indicates class must be thread-safe. Additional classes may also need to be thread-safe, depending on your design.):
After downloading the source, familiarize yourself with the Javadocs found here (and also in the zip file): API Specification
However, we emphasize that the goal of public tests is to verify the setup of your project - not to fully test functionality. You are responsible for the design and development of further tests to ensure that the functionality of your framework complies with the specification. There will be no release tests.
To add the test files to your project, just unzip the test.zip file into the project skeleton. To run the tests, which are JUnit tests, simply configure Eclipse to "Run As ..." a JUnit test.
One file, TestPublicTests.java, contains JUnit tests in single-threaded and multi-threaded contexts. The single-threaded testbed is based on an event-based Heap Sort algorithm. The multi-threaded testbed is a producer/consumer example. Study the JUnit tests for example usage of each testbed. You are welcome to develop your own tests based on these testbeds or to develop new scenarios.
NOTE: The provided tests do not make use of the MultithreadedTC framework discussed in class, but you are welcomed to use this framework in the development of your own tests.
Every file you submit should have your name and UID as well as (optionally) the name and UID of a partner. To enforce academic integrity, Code WILL BE CHECKED for similarity to other submissions. Each student should make his or her own individual submission, and only similarity with your partner's submission will be excused.
Submit your code on the Department's Submit Server. Contact the TA if you have any troubles submitting. There are 13 public tests, 0-12.
You are also required to submit a short "design document" describing the design choices you made in your logging framework. At a minimum you should detail where you added synchronization and why. Due to the non-deterministic nature of multi-threaded code, a significant portion of your project grade will come from manual inspection of your code, AS GUIDED BY THIS ACCOMPANYING DOCUMENT. Therefore, it is in your best interest to provide a sufficient amount of detail in order to reduce the chance for misinterpretation. You may submit this document directly to the TA via e-mail, one per team.
As promised, the project will incorporate a bit of competition. For this project, we will compare the designs of each submission. Authors of the submission with the best design as determined by its simplicity, correctness, clarity, performance, and the quality of the design write-up will win the cool T-Shirt. If we determine that multiple submissions exhibit equally great designs, a winner will be drawn from a hat of these submissions.