Advanced Programming in the UNIX® Environment

ptg10805159

496 Advanced I/O Chapter 14

We saw in Figure14.2 that Linux 3.2.0 and Solaris 10 provide mandatory recordlocking, but

FreeBSD 8.0 and Mac OS X 10.6.8 do not. Mandatory recordlocking is not part of the Single

UNIX Specification. On Linux, if you want mandatory locking, you need to enable it on a per

file system basis by using the-o mandoption to themountcommand.

Mandatory locking is enabled for a particular file by turning on the set-group-ID bit

and turning offthe group-execute bit. (Recall Figure4.12.) Since the set-group-ID bit

makes no sense when the group-execute bit is off, the designers of SVR3 chose this way

to specify that the locking for a file is to be mandatory locking and not advisory locking.

What happens to a process that tries toreadorwriteafile that has mandatory

locking enabled and that part of the file is currently locked by another process? The

answer depends on the type of operation (readorwrite), the type of lock held by the

other process (read lock or write lock), and whether the descriptor for thereador

writeis nonblocking. Figure14.11shows the eight possibilities.

Type of existing Blocking descriptor,Nonblocking descriptor,

lock on region held tries to tries to

by other process read write read write

read lock OK blocks OK EAGAIN

write lock blocks blocks EAGAIN EAGAIN

Figure 14.11 Effect of mandatory locking onreadsandwrites by other processes

In addition to thereadandwritefunctions in Figure14.11, theopenfunction can

be affected by mandatory recordlocks held by another process. Normally,open

succeeds, even if the file being opened has outstanding mandatory recordlocks. The

nextreadorwritefollows the rules listed in Figure14.11. But if the file being opened

has outstanding mandatory recordlocks (either read locks or write locks), and if the

flags in the call toopenspecify eitherO_TRUNCorO_CREAT,thenopenreturns an error

ofEAGAINimmediately,regardless of whetherO_NONBLOCKis specified.

Only Solaris treats theO_CREATflag as an error case. Linux allows theO_CREATflag to be

specified when opening a file with an outstanding mandatory lock. Generating theopenerror

forO_TRUNCmakes sense, because the file cannot be truncated if it is read locked or write

locked by another process. Generating the error forO_CREAT,however,makes little sense; this

flag says to create the file only if it doesn’t already exist, but it has to exist to be recordlocked

by another process.

This handling of locking conflicts withopencan lead to surprising results. While

developing the exercises in this section, a test program was run that opened a file

(whose mode specified mandatory locking), established a read lock on an entirefile, and

then went to sleep for a while. (Recall from Figure14.11that a read lock should prevent

writing to the file by other processes.) During this sleep period, the following behavior

was seen in other typical UNIX System programs.

•The same file could be edited with theededitor,and the results written back to

disk! The mandatory recordlocking had no effect at all. Using the system call

trace featureprovided by some versions of the UNIX System, it was seen thated