代写CSC2035、代写C/C++程序设计

日期：2022-11-03 09:01

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

1/11

CSC2035 Assignment 1 - systems programming and in-

ter-process communication (IPC)

Due 11 Nov by 15:00 Points 100 Available 10 Oct at 11:30 - 27 Jan 2023 at 10:00

Contents

1. Introduction

2. Aim

3. Learning/skills outcomes

4. Important context and expectations

5. The application/simulation

6. What you are given

7. What you have to do

8. Breakdown of marks

9. Deadline for submission and what to submit

1. Introduction

For this assignment you are provided with a partially completed project to demonstrate different

approaches to maintaining the integrity of an inter-process communication (IPC) application. The IPC

application is a collection of multiple process that communicate via a queue of jobs that is allocated in

shared memory (see Section 5).

Your task is to complete the project by implementing supporting library functions (see Section 7).

The project demonstrates both busy waiting and semaphore approaches to maintaining integrity of

IPC applications. This will reinforce, in practice, the operating systems theory you will learn as part of

this module. A fully working solution will be provided after completion of the assignment to allow you

to access all learning outcomes even if you are unable to complete the project yourself.

2. Aim

The aim of this assignment is to give you experience of and help you to draw lessons from:

use and implementation of shared memory and IPC facilities

simulating and exploring system behaviour

the modular design of systems and implementation of appropriate abstractions

use of the standard C library and the POSIX system interfaces

programming to interface, where the functions you have to implement are defined in a set of

header files

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

2/11

programming to tests, where a complete suite of tests is provided for the libraries you implement

and the libraries that are provided for you as part of the project

analysis of and modification to an existing codebase

3. Learning/skills outcomes

Practical understanding and application of operating systems concepts including: processes,

scheduling, resource management and IPC

C programming skills

Programming using a system interface

Implementing a specified interface

Programming to test

Code comprehension skills - understanding, analysing, using and modifying code provided by

others

An understanding of the place of your own work in the context of a larger system

The formulation of problems and identification of suitable approaches to solving them

Cognitive/intellectual skills and self management

4. Important context and expectations

The coursework specification comprises:

this document

README files provided with the codebase that give additional instructions and advice

the function specifications written in comments in header files in the codebase

You are expected to familiarise yourself with this material. Advice and instructions, including things

you must do, may be in this document or in comments in source code (.c or .h files) or in the

README filles. Ignoring such advice and instruction may lead to loss of marks.

You are also expected to read the documentation associated with relevant parts of the standard C

library and the POSIX interfaces. This documentation is mostly in man (or manual) pages you access

using the Unix man command or via Web-based man pages.

You can work on this assignment on any POSIX-compliant system (including a virtual machine). See

the module resource on setting up your C programming environment for information on the

different ways to do this. The University cs-linux.ncl.ac.uk service is the reference system for

the coursework. This means that we will use cs-linux.ncl.ac.uk to compile and run your solution

when we are marking your work. Therefore, regardless of how you choose to work, you should test

your solution on cs-linux.ncl.ac.uk before you submit it.

There are references to the "user" in the materials provided. This means a programmer (including

yourself) who uses a library function in their program. The library function may be from a system

library, may be one of the functions provided for you or may be one of the functions that you have to

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

3/11

implement. In all cases, the user of the function is the programmer who includes a call to the function

in their code (as opposed to an end user of an application). Sometimes the process calling a function

is referred to as the user of the function.

You are completing the implementation of libraries not an application program. Applications and tests

that use the libraries are provided for you. There is no need to write any other application

programs. That is, you should not write a main function for this assignment.

Library functions do not normally produce output to console because the destination for output is an

application-level concern. Therefore, there should not be any printf or perror or other such

statements that produce output to stdout or stderr in the implementations you submit. If you use such

output for debugging when you are working on the assignment, remove it before submitting your

solution.

Each library in the codebase has a corresponding test (in the test directory). These tests give you

valuable feedback on whether your implementation is successful. The test source code is also

instructive. From the test source code, you can often work out what a library has to do and even

some of how it should be implemented.

There will be two releases of the project codebase:

Release 1 is the complete codebase for the libraries to develop along with an almost complete

suite of tests. Tests missing from release 1 are for the queueing libraries.

Release 2 will complete the test suite and provide the applications that use the libraries you

develop. This may be separated into two releases, with tests suite first then the applications.

This project can be seen as a collaborative development with me and it is normal in a collaborative

development for there to be staging of releases. This mirrors industry practice. Do not wait for the

release 2 to start work on the assignment. You can work on all parts of the assignment (including

queueing aspects) without release 2. You can even write your own queueing tests if you wish. That

is, the staging of releases does not mean a delay to your work. When you have release 2, you

will be able to complete all testing and the correction of your work in order to pass the release 2 tests.

Do not submit your work until you have tested it with the complete test suite provided in release 2.

Altogether, the main codebase comprises over 20 (.c and .h) source code files (of which you are

expected to complete the implementation of 5 files). In addition, there are over 20 source code files in

the test directory. In a project of this size, it is possible that there are bugs in the code that is provided

for you. It is possible therefore that bug fixes will be released when you are working on the

assignment. This is also normal. In addition, advice, clarification, documentation and README files

may be released after release of the initial codebase. Once again, this is normal. This will give you

experience of how in a real world projects things can change during development. The specification

of the functions you have to implement will not change and no changes to the codebase will be

released in the week before the assignment is due.

You must not change function signature in header (.h) files. Header files will only change if I

release an update that changes them.

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

4/11

Contact me if you need clarification of the project requirements or need help interpreting

documentation or need help to solve programming problems. See the guidance on asking for help.

If you think you have found a bug in the codebase, please use the form you can access from the

same page.

5. The application/simulation

As shown in the following figure, the overall project simulates an application in which a set of one or

more producer processes create jobs to submit (enqueue) to a priority job queue for one or more

consumer processes to dequeue and process. The use of a priority queue means that each job has a

priority associated with it and jobs will be dequeued in priority order (highest priority job first). The job

queue is in shared memory. In addition each process (producer or consumer) has a private persistent

log of jobs that they have produced (if they are a producer) or consumed (if they are a consumer).

Many common client/server applications follow this model of one or more producers (clients)

submitting work to be done by a one or more consumers (servers).

The overall application proceeds as follows :

While a producer process has jobs to be done, they produce a job, assign a priority level to the

job, enqueue the job on the job queue and log the job in their private log. A producer is made to

wait to enqueue a job if the queue is full. If there are multiple producers, they should not able to

overwrite each other's jobs despite sharing the same queue.

While there are jobs to consume, a consumer process dequeues the next job from the queue

(which will be the job with the highest prioirty on the queue), logs the job in their private log and

processes the job. A consumer ismade to wait to dequeue a job if the queue is empty. If there are

multiple consumers, each job is only consumed by one consumer despite sharing the queue with

the other consumers.

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

5/11

A job is represented by the following attributes:

the process id (pid) of the producer of the job

a job id generated by the producer of the job that is locally unique to that producer

a priority level with 1 being the highest priority, then 2 and so on. Priorities are not unique. Two

distinct jobs may have the same priority.

a job label - an application-specific string that, for example, may describe the job

The combination of job pid and id means that, assuming integrity constraints are maintained, each

job will be globally unique even when multiple producers are producing jobs. The job id that is locally

unique for a given producer is made globally unique for all producers by qualifying the job id with the

producer's globally unique pid.

In a real-world version of the application, the combination of pid and job id could be replaced by an

absolute URL that is qualified by the producer's domain name. The label could be replaced by a URL

link to a job specification.

The C application code for the producer and consumer processes that drive the simulation will be

provided for you in the release 2 (or subsequent release) of the assignment. Your task is to complete

libraries that support the simulation (see Section 7). You are not writing the whole application (or all

of the library code). You do not write the producer or consumer applications. Application code in

release 1 is the test suite provided for you to test your library code.

The overall integrity constraint of the application is that producers should not produce duplicate jobs

and each job should only be consumed once by one consumer. That is, no two consumers should

consume the same job. If you complete the libraries specified in Section 7, when the producer and

consumer applications are released you you will have a project that demonstrates whether this

constraint holds for different approaches to concurrency control.

Whether integrity is maintained can be verified by checking whether the states of log files after a

simulation run satisfy the following conditions:

1. Jobs are well-formed: entries in logs are as specified in the joblog.h file.

2. Logs are sets: no producer log contains duplicate entries and no consumer log contains

duplicate entries

3. No jobs are lost: every job that appears in a producer log has a corresponding entry in one of

the consumer logs

4. Consumers do not create jobs: every job that appears in a consumer log has a corresponding

entry in one of the producer logs

Conditions 2, 3 and 4 mean that the union of producer logs equals the union of consumer

logs. That is, for producer logs P to P and consumer logs C to C :

P ∪ P ∪ ... ∪ P = C ∪ C ... ∪ C

5. There is no duplication of jobs between consumers. Each job is consumed by one and only

one consumer. That is, each pair-wise intersection of the set of consumer logs is the empty set:

for each and every pair of consumer logs C and C , C ∩ C = ?

0 n 0 m

0 1 n 0 1 m

i j i j

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

6/11

In addition, from the set of jobs in the queue at any one time, jobs are consumed in priority order.

This is not an integrity constraint and it does not imply a total ordering of all jobs by priority. It simply

means that, if the queue implementation is correct, for the set of jobs in the queue at any one time,

the highest prioirty job is dequeued first. This will be verified by queueing tests.

Further information about the overall simulation, how to run it and how to analyse the process logs,

as well as how to run tests of libraries, will be provided in README files. When the producer and

consumer applications are released, scripts will be provided for you to run the applications and to

analyse logs after each simulation run.

After completion of the assignment, and as part of your feedback, a working solution will be released.

This will allow you to access all the learning outcomes even if you are unable to complete the

assignment correctly.

6. What you are given

The codebase is provided in two releases.

Release 1 - the initial codebase

Release 1 is the initial codebase that includes all the libraries that you have to complete along with

tests for libraries.

Download the initial release of the codebase as either a zip file or tar-gzipped archive:

csc2035-assignment1-r01.zip (https://ncl.instructure.com/courses/45145/files/6141403/download?

download_frd=1) , or

csc2035-assignment1-r01.tgz (https://ncl.instructure.com/courses/45145/files/6141404/download?

download_frd=1)

This contains:

an initial README file that tells you how to build and test the libraries you implement

a Makefile and associated configuration files to build the project

the source code for the following project libraries, including the .c files you have to complete (for

the libraries in bold):

ipc - an encapsulation of shared memory

ipc_jobqueue - a shared memory wrapper for a job queue

job - the representation of a job

joblog - a facility to log jobs to file

pri_jobqueue - a priority job queue

proc - the representation of a process in the application

sem_jobqueue - a semaphore based monitor for controlled access to a shared memory job

queue

shobject_name - a utility to generate well-formed names for shared memory objects

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

7/11

the test source code for the above libraries in a test sub-directory. The queueing tests (for

ipc_jobqueue, pri_jobqueue and sem_jobqueue) are currently incomplete. They simply output that

the tests are skipped. Complete tests will be provided in release 2. Do not let this delay your work

on the assignment or even on the queueing implementations. You can make progress on all

aspects of the project that you have to implement without the complete tests.

a shell script (runtests.sh), to run tests.

You start by reading the initial README file: README01.txt

Release 2 - to complete the codebase

Release 2 completes the codebase with the queue test suites and the simulation applications to

demonstrate different approaches to concurrency controll. Further information will be provided when

the code for release 2 is made available.

7. What you have to do

You have to complete the implementation of the functions with a TODO comment in the following .c

files.

job.c - the representation of a job

joblog.c - logging functions

pri_jobqueue.c - the definition of and functions to manipulate a queue of jobs based on a fixed-

sized array with priority order dequeing of jobs. It is your implementation decision whether jobs

are stored in the queue in priority order. The requirement is that they are dequeued in priority

order. See documentation in pri_jobqueue.h and pri_jobqueue.c for further information.

ipc_jobqueue.c - wrapper functions for a queue of jobs that is stored in shared memory for IPC

sem_jobqueue.c - wrapper functions for a queue of jobs that is stored in shared memory and that

is protected by semaphores to satisfy integrity constraints

If you think it will help to reduce code duplication or simplify logic, you may define your own private

helper functions in the above files.

Do not modify any files other than those listed. Do not modify any functions other than those

specified by a TODO comment in the files listed. Comments in files clearly state which files you

should edit and which functions in those files you should implement. A "TODO" comment means that

you have to implement a function or complete its implementation. A "DO NOT EDIT" comment

means you do not edit the file, declaration or function with which it is associated.

The specification of the functions you have to implement is given in corresponding header (.h) files,

i.e. see joblog.h for the specification of the functions in joblog.c.

README files, this assignment specification, comments and hints in the .c files etc. provide

additional guidance for completing the assignment.

How to work and programming to test

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

8/11

1. Compile the project and run the tests as instructed in the README file provided. You will see that

tests fail. Your job is to complete the project until no tests fail.

2. The suggested order to implement the libraries is:

1. job.c because the other libraries depend on job.c

2. joblog.c because it does not rely on an understanding or queueing or IPC

3. pri_jobqueue.c because the other queue implementations depend on pri_jobqueue.c

4. ipc_jobqueue.c

5. sem_jobqueue.c

3. For each .c library file, after making changes, compile the project again and run the tests.

4. Keep working until all tests succeed for a given library. You can run tests for all code or for an

individual library file.

That is, program to the tests provided. README files gives instructions on compiling and running test

programs and provide examples of expected output.

A note on dependencies

There are the following dependencies between the libraries:

joblog.c depends on the "public" interface of job.c (as defined in job.h)

pri_jobqueue.c depends on the "public" interface of job.c (as defined in job.h)

ipc_jobqueue.c and sem_jobqueue.c depend on the "public" interface of pri_jobqueue.c (as

defined in pri_jobqueue.h)

These dependencies mean, for example, it is not possible to properly test joblog.c without a working

implementation of job.c. However, even if you cannot test it properly, you can attempt to implement

joblog.c without implementing job.c because joblog.c will invoke functions in the interface defined in

job.h and not access implementation detail. That is, do not give up just because you do not know

how to implement job.c. Move on to the libraries, parts of which may be implemented in terms of

the job.h interface.

When we mark your work we will test and mark each component independently. That is, for example,

we will test and mark your implementation of joblog.c with the specimen solution to job.c and not your

solution and so on. This ensures you are not disadvantaged by the dependencies and that an

incorrect solution to job.c does not prevent you gaining full marks for joblog.c, for example.

Additional advice

This project does not involve complicated or innovative programming. It is mainly an exercise in

code and project comprehension. The difficult part is understanding what you have to do, and

understanding how to apply examples and other code you have been given. This does not mean

you should delay starting. It will take time to understand all the information you have been given

and to determine what you have to do. You will find this assignment very difficult, if not

impossible, if you leave it to the last week before submission date.

Start now (teaching week 3) with familiarising yourself with the code you have been given and

processing all the other information you have been given.

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

9/11

Do not reinvent the wheel. It is OK to use and adapt code that is provided in examples in the

module and/or in the codebase provided (including the test code). Test code is a good place to

look for what is expected of a function. It may also give you ideas for how to implement the

function. And don't just look at the tests directly related to a library. That is, look at test_job.c to

help with implementation of job.c and also look at test_joblog.c and test_pri_jobqueue.c (when

provided). These other tests may have useful example code that will help with the implementation

of job.c.

As with any assignment, do not use or copy each other's code.

Research the C libraries for functions you use. Look at the man pages for any functions from the

C and system libraries you use. Understand what the return values of library functions mean and

what the error conditions are.

You will get the most out of this project if you also do formative work for the module and attend

associated workshops and demonstrations.

A note on commenting code

You do not need to comment your code. In fact, it is better that you do not comment your code. You

can add comments for your benefit but it would be better to remove them before submitting your

work. In any case, we will ignore comments that you add to code.

The reason for this is that comments can easily get out of sync with the code that they comment. This

is a maintenance problem. Code should be simple and clear enough to explain itself. Therefore, in

general, you should only provide comments to the external interface to your code. These are already

provided for you in this project and there is, therefore, no need for additional commenting.

8. Breakdown of marks

The total mark for this assignment is 100. It is worth 50% of the coursework component of the

module and 17% of the module mark.

The indicative breakdown of marks for each part of the assignment is as follows:

ipc_jobqueue.c - 10 marks

job.c - 30 marks

joblog.c - 15 marks

pri_jobqueue.c - 25 marks

sem_jobqueue.c - 20 marks

For full marks your solution must:

Compile without compiler warnings and run on the reference sysem cs-linux.ncl.ac.uk, and

Pass tests for the above files (some of which may be more comprehensive than the tests

provided with the codebase), and

Comply with instructions given in this specification and related material (including in relevant .h

files, .c files and README files), and

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

10/11

Demonstrate good programming practice particularly with respect to non-functional aspects.

Good practice includes (but is not restricted to):

Not overcomplicating solutions

Guarding against memory leaks

Safe use and choice of system and C library functions

Where appropriate, programming defensively with respect to input parameters to functions

and return values of functions you use. "Where appropriate" means that there is a trade-off

between programming defensively and not over-complicating your solutions. However, you

should guard against propagation of errors to the underlying system. The specification of

functions will give some indication of what is expected in terms of managing errors and

erroneous input.

9. Deadline for submission and what to submit

Your coursework must be submitted to the NESS system by 15:00 on Friday 11 November 2022.

The deadline is rigorously imposed by NESS. Work that is a few seconds beyond the submission

deadline will be flagged as late.

You submit your versions of the files listed in Section 7 in a directory called csc2035-assignment1-

submit in a zip or tar-gzipped archive. That is, a zip archive called csc2035-assignment1-submit.zip

or a tar-gzipped archive called csc2035-assignment1-submit.tgz with the following contents:

csc2035-assignment1-submit/

ipc_jobqueue.c

job.c

joblog.c

pri_jobqueue.c

sem_jobqueue.c

You can use the command:

make submission

to create your submission archive.

Do not submit any other files. Anything other than the files listed above will be ignored. Submitting

your files in the csc2035-assignment1-submit directory means that they can be tested automatically

by our markers.

Each of the .c file should start with the following comment:

/*

* Replace the following string of 0s with your student number

* 000000000

*/

where, as instructed, you replace 000000000 with your student number.

CSC2035 Assignment 1 - systems programming and inter-process communication (IPC)

11/11

Do not submit your work until you have tested it on cs-linux with the complete tests in release

2 of the codebase.