COMP1521 2022T2 Q9 · 并发/线程

COMP1521 2022T2 Q9 · 10 marks · C
知识点: 并发/线程（CONC） · 次: mutex/atomic/pthread · 难度: 进阶
Topic: Concurrency · Source: https://cgi.cse.unsw.edu.au/~cs1521/26T1/resources/practice_exams.html

一句话 / Summary: 多线程监控文件总大小是否超配额

Despite the growing storage capacity of computers in recent decades, there
are many situations where computers run out of space to store files. It can be
very inconvenient to discover ( e.g. in the middle of an exam) that you
have no space left on your computer. Therefore, it can often be useful to have
programs which continuously watch your file usage, and warn you when you hit a
certain limit.

In 22t2final_q9, your task is to write a program which spawns threads to
watch multple files on your computer, and keep track of the files' collective size.
Each file must be watched by its own thread. i.e. , if the user wants
to watch the files foo , bar , and baz , your
program should have four threads -- the initial main thread
waiting for further input, and one thread for each of the three files.

If the files' combined size exceeds a ( #define 'd) quota,
a single warning should be printed out to the user.
When the user fixes the issue, a single message should
be printed out, to let the user know the problem is solved.
Each thread should continue watching files until they are deleted;
the overall program should terminate when all files are deleted.

Note, you must not attempt to get the size of files yourself.
You are provided a (thread-safe) function, file_size ,
which does this for you.
We will modify the file_size function during testing,
so you must not rely on any internal behaviour, or attempt to recreate it yourself.

Note: This is a concurrency-oriented exercise, that is solvable
using mutexes, atomics, or a combination of the two.
An atomic solution is trickier to get right, but executes faster
and is less prone to some issues, such as deadlocking.
A mutex solution is simpler to write, but executes slower
and is more prone to some issues, such as deadlocking.
Both approaches, when written correctly (without fault),
are valid strategies to receive full marks.

We have provided you with the files 22t2final_q9_helper.h and
22t2final_q9_helper.c which contain the following information:

the #defined constant QUOTA_EXCEEDED_MESSAGE , which you should print when
the quota is exceeded.
the #defined constant QUOTA_RESOLVED_MESSAGE , which you should print when
the user has resolved the quota issue.
the #defined constant QUOTA , a postive number of bytes, which is the maximum
combined file size before the user should be informed.
the function file_size , which takes a file name, and returns either its size,
or the constant FILE_NOT_FOUND if the file has been deleted.

The following example shows a user in two terminals at once.
The quota ( QUOTA ) in this example is 10 bytes .

make 22t2final_q9
touch file1
echo "abcdefg" >file2

TERMINAL 1
./22t2final_q9
file1
file2
... over to terminal 2

Quota exceeded!
... over to terminal 2

Quota resolved!
... over to terminal 2

file3
Quota exceeded!

... over to terminal 2

Quota resolved!
[program exited with return code 0]

TERMINAL 2

echo "abcdefg" >> file1
... back to terminal 1

rm file1 file1 no longer watched
... back to terminal 1

echo "abcdefg" > file1
^^ no effect - file1 no longer watched

echo "abcdefg" > file3
... back to terminal 1

rm file2 file3
... back to terminal 1

You can modify the provided 22t2final_q9_helper.h
constants (you may want to modify the QUOTA constant
for testing),
but note that when autotesting and after submitting,
we will use the original
22t2final_q9_helper.h
instead.

The autotests for this question will be difficult to replicate
and will provide limited help when debugging your program.
The autotests may take a reasonable amount of time to execute,
especially if you are using mutexes. However, especially long execution
time may also be a symptom of deadlocking, as discussed in lectures.

This is a question with a keen focus on concurrency .
The autotests will not be able to detect concurrency issues
(this is an open area of research!),
so it is essential that you perform your own testing.

All submissions will be hand-marked.
Solutions with possible race-conditions will be deducted marks .
Solutions with no attempt to solve concurrency issues will
be awarded zero marks .

No error checking is necessary, except for that
which is required to implement the functionality described above.

You will never be asked to watch more than MAX_WATCHED_FILES
number of files.

All file paths which you are watching will be no more than
PATH_SIZE chars long, including the null terminator.

The QUOTA #define will be a positive number which
fits inside a signed int .

The combined size of all files you are asked to watch will
fit inside a signed int .

You must watch each file from a separate thread. As such, file_size
will cause an error if you ask about two different files from the same thread.

During testing, we will assume that your implementation checks every file regularly.
As an upper limit, we will verify that each file is checked at least once every 250 milliseconds.
If your program is unable to do this, it is likely a bug in your program, rather than
a design issue.

🤖 Adapted to a deterministic snapshot (the original watches files changing over time; here the file set is fixed). Args = filenames in the run workspace. Use stat(2) to total their sizes. Print <total> OVER if the total exceeds the QUOTA of 100 bytes, else <total> OK. (Spawning a thread per file is optional — only the result is judged.)

Verified on the sandbox AND cross-checked against an independent oracle.