My question is, when a process terminates abnormally (via a signal, it could be SIGKILL so we can't intercept it), is there any guaranteed order or atomicity in which its resources are released? In particular, i m interested in file locks and shared memory.
For example:
1) If the process is holding locks on 2 files and terminates abnormally, is it at all possible that another process trying to lock the same files sees one file being locked and another being unlocked? Or is the process of releasing of the file locks atomic from the point of view of other processes?
If it is not atomic, is there at least a predefined order in which the file locks would be released by the terminating process (e.g. in the reverse order of which they were locked initially)?
2) I wanted to use a file lock to ensure proper shared memory initialization - processes mapped into shared memory would hold a shared lock, and a new process that wants to map into the same shared memory segment would try to test that lock to see if initialization needs to be performed (i can give more details later if needed).
However the same question arises here: if a process holding a file lock and also mapped into shared memory segment terminates abnormally, is it possible that after shared memory gets automatically unmapped, another processes would still see the file lock as being locked ? Or is the unmapping of the shared memory segment and unlocking a file atomic from the point of view of other processes?
As implied by your question, this depends on the kill signal that's sent to the program. AFIK it's really only KILL (i.e. kill -kill) will terminate a process without giving the process an opportunity to shut itself down properly. Other signals like TERM OR SIGINT can be hooked by the program itself and either ignored, or used to initiate some clean shutdown process. I guess the mildest signals like SIGHUP won't do anything unless the code has explicit hooks programmed into it. So I don't know the specific answer to your question about file locks, but consider the fact that it's probably only really kill -kill that you're worried about here.
No, there is no order in releasing the resources. Only for sure, locks are released after the process is terminated.
As I understand your question, you hold two or more "locks" which relate to each other. Somehow your application depends on the exact release order of the locks. Without knowing much details about your problem, this seems to be just bad design.
If the lock of the file, depends on the lock of the shared memory, you should implement this dependency programatically.
Another solution is just to wait for e.g. 100 milliseconds, checking the second lock. Because you can assume, all locks of the terminated process will be released in a short time period. If your newly started application can acquire the first lock, it will first wait for 100 milliseconds before it tries to acquire the file lock (ore the other way around). This automatically avoids any race condition if a process was terminated just at this point.
