CSCI 4320 (Principles of Operating Systems), Fall 2009:
Homework 5

Credit:

10 points.

Reading

Be sure you have read, or at least skimmed, Chapters 6 and 9.

Problems

Answer the following questions. You may write out your answers by hand or using a word processor or other program, but please submit hard copy, either in class or in my mailbox in the department office.

1. (5 points) Suppose you are designing an electronic funds transfer system, in which there will be many identical processes that work as follows: Each process accepts as input an amount of money to transfer, the account to be credited, and the account to be debited. It then locks both accounts (one at a time), transfers the money, and releases the locks when done. Many of these processes could be running at the same time. Clearly a design goal for this system is that two transfers that affect the same account should not take place at the same time, since that might lead to race conditions. However, no problems should arise from doing a transfer from, say, account $A$ to account $B$ at the same time as a transfer from account $C$ to account $D$ , so another design goal is for this to be possible. The available locking mechanism is fairly primitive: It acquires locks one at a time, and there is no provision for testing a lock to find out whether it is available (you must simply attempt to acquire it, and wait if it's not available). A friend proposes a simple scheme for locking the accounts: First lock the account to be credited; then lock the account to be debited. Can this scheme lead to deadlock? If you think it cannot, briefly explain why not. If you think it can, first give an example of a possible deadlock situation, and then design a scheme that avoids deadlocks, meets the stated design goals, and uses only the locking mechanism just described.

2. (5 points) Programs or program updates sometimes come packaged as ``self-extracting archives'', which combine the files that make up the archive with a program to extract them. Compare this with other ways of packaging programs and updates (e.g., as RPMs or tarballs) with regard to security and any other factors that seem relevant.