Guardian Programmer's Guide

Table Of Contents
Coordinating Concurrent File Access
Guardian Programmer’s Guide 421922-014
3 - 7
Avoiding Deadlocks
You can specify that read operations should finish normally and that data should be
returned in the buffer even though another process has the file locked. You should
be aware, of course, that the process that has locked the file might change the
record after the process reads the record:
LITERAL READ^THROUGH^MODE = 2;
.
.
CALL SETMODE(FILENUM,
SET^LOCK^MODE,
READ^THROUGH^MODE);
Refer to the Guardian Procedure Calls Reference Manual for a complete description of
all SETMODE function 4 options.
You can obtain information about file locks, such as how many processes hold locks on
the file and how many processes are waiting for file locks, by calling the
FILE_GETLOCKINFO_ procedure. Refer to the Guardian Procedure Calls Reference
Manual for details of this procedure.
Avoiding Deadlocks
There are two kinds of deadlocks your process might encounter:
Multiple-process deadlocks
Single-process deadlocks
The following paragraphs describe each kind of deadlock and how to detect or avoid
them.
Avoiding Multiple-Process Deadlocks
Figure 3-2 shows an example of how two processes competing for resources are able
to cause each other to wait indefinitely. This kind of situation is known as a deadlock.
Note.
²
You can apply locks to records as well as files. You apply a lock to a record using the
LOCKREC procedure and remove the lock using the UNLOCKREC procedure. You can
manipulate record locks in all the ways described above for file locks. See Section
5,
Communicating With Disk Files, for more information on disk-file records.
²
Throughout this section, the default of waited I/O has been assumed. In cases where the
process is described as waiting for some kind of response, the rules might change if
nowait I/O is used. Nowait I/O is described in the next section.