EEE6207讲解 、辅导 C++程序设计
EEE6207 Coursework Assignment AY2024-2025
You will write and test a small C program that implements a model of a number of independent Producer and Consumer entities that fill and drain a FIFO queue. C models are often used to emulate the behaviours of various hardware, software and distributed computing systems, including the operating systems themselves. Examples include determining how big a buffer should be sized so it doesn’t cause stalling and underutilisation in a new hardware microarchitecture or designing a new scheduling or i/o strategy within user or operating system software.
We won't be doing any analysis on the model we write here in a way a microarchitect or operating system architect would. Still, this sort of exercise, which includes an element of random traffic modelling, is definitely something you might see used to help size a system or even determine how big a run queue in an operating system or web server implementation might be.
The coursework will utilise concepts of multiprogramming and synchronization that have been covered in lectures and notes and draw on practical programming examples primarily from the labs on processes, threads and synchronization.
Model Specification
Implement a C-code model that emulates a system with n Producers and m Consumers which interacting through a shared queue
Each Producer process (Pn) should generate a stream of random integers, writing them into a shared queue. It should then wait for a random number of seconds (up to some specified maximum value) before attempting its next write.
Each entry into the queue should have a priority (low, normal, high} assigned to it
Each Consumer process (Cn) should read an item from the shared queue if one is available and display it to the standard output. It should then wait for a random number of seconds (up to some specific maximum value) before attempting its next read.
The queue should be implemented as a first in, first out, FIFO, data structure.
If there is more than one item in the queue a high priority entry should be read before any normal or low priority entries
A Consumer Process must not read from an empty queue.
A Producer Process must not write to a full queue.
To avoid the model from consuming unnecessary resources on the computing platform on which it will be run, your model must include a mechanism to stop its execution once a specified Timeout Value (in seconds) has been reached.
Run time behaviour of the model should be controlled through a set of command line arguments specifying the following parameters:
Number of Producers (between 1 and 4)
Number of Consumers (between 1 and 4)
Maximum entries in the queue (between 1 and 20)
Timeout Value in seconds
The following default parameter values should be built into the model. These should be easily identifiable (using appropriate comments and code structures such as include files) such that they can be configured through recompilation of the model source code.
Maximum wait period between Producer writes 4 seconds
The maximum wait period between Consumer reads 4 seconds
Maximum number of Producers: 5
Maximum Number of Consumers 4
Range of Random Number generated by Producer 0 to 9
Your model should display an appropriate level of user-visible information while it is executing and a concise, readable summary of the model run itself. This must include the following information.
Run time Command line parameters.
Compiled model parameters
Time & date of the execution run
Current user name & hostname
Indication of the current state of Producers, Consumers and the Queue
Comments & Code Structure
Please make sure you comment your code well – readability is a part of the assessment criteria. Comments make your code readable both to yourself and others. As noted, you should especially make it clear where compile-time options that control model behaviour are identified and consider the use of an appropriate code structure that provides modularity. Hint: A random number needs to be generated as data in the Producer process, and as a variable random wait in both the Producer and Consumer processes, one function will suffice.
Error Handling
We have emphasised the need to ensure the code handles error conditions, for example, those returned from system calls, well. What are you going to tell the user if a function or system call you use does not return the expected value?
Model Verbosity
Your model should output an appropriate level of information to the user as it is running so she can track progress. It is up to you, but a suggestion would be to log when a Producer writes to the queue, including which producer it is and what it writes. This should, of course, include when a consumer writes to the standard output. Summarising the command line parameters for the model run is required.
Debugging
If your code is ‘working’ it should produce expected outcomes. How will you or a user debug a problem? You should include additional detailed instrumentation in your code to provide information about what is happening and a mechanism to turn this on or off – this could be a compile time option or a run time argument, your choice. The default behavior however should be off - see the comment about Model Verbosity above.
Tidying up
Before you program exits it should exhibit good behaviour and clean up after itself. If for example it has created thread resources or synchronization objects it should cleanly terminate or relase these, returning the associated memory resources to the operating system.
Assessment Criteria
Your coursework should be submitted no later than 5pm on Friday February 7th (this is the last day of Semester 1). This assignment is worth 25% of the total module mark and is a must pass element.
You will submit a zipfile (not a .rar or tarfile) bundle to a blackboard assignment. This contains the following sections. You will be provided with the exact details of how to do this through the assignment portal
a)File(s) containing your (appropriately commented) c code that implements the specified model functionality, this should include error handling and instrumentation.
b)A short report describing your code structure, key features of your model implementation and commentary on your two output run logs. {Max 200 words}
c)Two separate run logfiles that use different command line parameters demonstrating the functional execution of your code
Your submitted c-code will be
Run through MOSS to check the code for similarity (plagiarism check). (https://theory.stanford.edu/~aiken/moss/)
Recompiled and re-run to check it works consistently with your log files and with a separate run using a different parameter set
Marking scheme – Must pass threshold for MSc module is 50%
C code and associated report 65%
Run logs and Code rerun 45%
Hints
This assignment will almost certainly require you to search to identify some specific programming constructs that you might not have used before or encountered in the practical lab exercises. It uses the foundational concepts of threads and synchronisation mechanisms that you have learned in those lab exercises, including mutex and semaphores, and the principles outlined in the lectures and notes.
The queue in your model should be safely and efficiently controlled using appropriate synchronization mechanisms. You could, for example, include mutexs and or semaphores.
Generating a logfile: You can pipe the output printf’d to the std_out terminal window into a file using the > operator in the shell. For example ./a.out > logfile will redirect the stdout into the file logfile
Generating user id and hostname can be accomplished using the getpwuid(getuid()) and gethostname() functions please put these in it identifies the runs as yours.
If (MY_PARAMETER) {
// do something
}
Is a simple way to insert conditional instrumentation code you only want to happen when you require the additional messages to be output.
Approach
You should consider approaching this assignment in a modular fashion. Break the problem down. write and test component functions as small independent chunks before integrating them together. For example, the random function mentioned earlier can be independently checked, as could, for example, the code to create a set of threads that would model independent consumers or producers or that which parses and displays the run time command line arguments.
It is entirely possible that there will be more error handling and optional debugging/ instrumentation lines of code and comments than there are functional lines of code
The number of lines of code you end up with obviously depends a little on style but a couple of fully commented – fully instrumented model implementations are in the range of 250-350 lines of code quite a few of these are things like #includes #defines etc
You will find examples of almost all of the building blocks need to complete this assignment in the practical class notes.
If you are unsure about any aspect of the assignment please reach out.
We will run additional drop in sessions for the remaining weeks of the semester