List and explain three methods that cooperating processes could use to coordinate their access to a file in order to prevent data loss or corruption.
1. Advisory Locking
This is a POSIX interprocess communication mechanism. this permits any part, or multiple parts, of a file to be marked as locked. The operating system does not enforce locking, but processes are expected to be well behaved and to look for locks on a file before doing anything that would conflict with another process.
2. Signals
A process A can send a signal to other processes every time it opens a file and another signal when it closes it. This way the other processes can set up variables in the program to remember which files are open and will not try to access those files. When the processes recieve the signal indicating that file is closed, they can again update their variables and access the file for their purpose.
3. Lock file as a locking indicator
The processes can create a lock file before accessing any file in the system. Any other process that is trying to access the same file can see the lock file and wait till the lock file is deleted by the first process before accessing the file. This way only one process accesses the file when it needs 'write' to the file.
TA notes: More than three possible, maybe mandatory locking and/or semaphores etc., You can even get creative and write your own methods as long as they are very distinct from one another you can get full credit. Only partial credit if you list similar methods with only few differences.
Problem #2
Of the three methods you listed in Question 1, which method do you think is the best method to use in order to coordinate file access ? List and explain two advantages of this over each of the other methods.
TA notes : Answer could be any of the three, it really depends on your perspective. Full credit as long as you have the right reasons. Also if the same reasons hold for both methods you can get full credit for just two reasons.
Lets go with Advisory Locking as it seems to be the best.
Adv over signals :-
(i) Inefficient and slow implementation. A useful amount of time might be wasted by the system in first setting up signals, then actually sending signals among processes and finally when handling the signals.
(ii) It would be difficult to control access to parts of a huge file through signals. Advisory locking easily enables locking of parts of a big file. So multiple processes can work on the same file at a time.
(iii) UNIX does not support a lot of standard signals and this could pose problems between processes that share a lot of files.
Adv over lock file implementation :-
(i) Lockfile could be accidentally deleted. Then access to the file will no longer be well-coordinated.
(ii) To create the process may not have enough permissions in the given directory.
(iii) It would be difficult to control access to parts of a huge file using this mechanism. Advisory locking easily enables locking of parts of a big file. So multiple processes can work on the same file at a time.
(iv) A process might forget/ignore to delete the lockfile after it is done with it, leaving the file locked for ever.
TA notes: May not be big advantage since even in advisory locking we rely on the fact that processes are cooperative. But it maybe easier to implement checks on advisory locks on a file by going through the table every now and then and seeing if the process is alive or not. Checking for lockfiles might more complicated and inefficient for the OS.
(iv) It takes up some amount (though very less, around 20 bytes) of memory in the user directory.
Problem #4
A user typing control-C at the keyboard will cause a SIGINT signal to be sent to the program. Several ways that you could implement a program to prevent it from being interrupted as follows:
1. Let the program to ignore the signal. You can set the action to be taken upon receipt of the signal to be SIG_IGN so that the signal will simply be ignored and the program will continue the processing.
2.The program could block the signal. You could create a mask that contains the SIGINT signal. Then the signal will be blocked( that means that they will not be handled until the process has completed or you tell explicitly to unblock it).
3. Have the program handle the signal ( take a specified user - defined action upon receipt of the signal). You can set the action to be taken upon receipt of the signal to execute a user-defined signal handler function that could do nothing or just notify you that you receive the signal and do nothing or whatever else you want it to do.
4. Non canonical mode- A non canonical mode could be set up such that the key strokes Ctrl-C could be caught and ignored.
Problem #5
System Calls----i-node---------Normal file block---------Directory block
1.lstat-------- no change-------no change--------------no change
2.lseek-------- no change-------no change--------------no chnage
3.fcntl-------- no change-------no change--------------no change
4.mkdir--------modify---------no change--------------modify
5.chdir--------no change-------no change--------------no change
6.opendir------no change--------no change-------------no change
7.link----------modify---------no change--------------modify
8.unlink--------modify---------no change--------------modify
9.open---------modify----------modify----------------modify
10.read--------no change-------no change--------------no change
11.write--------modify----------modify---------------no change
12.stat---------no change-------no change--------------no change