⎕FHOLD is used for synchronizing
access when multiple users and/or tasks are reading or writing the same file or
files. It takes a single argument,
which is usually a vector of tie numbers. If you need to supply pass numbers, the argument is a 2-row matrix of tie number/pass number pairs. The
tie numbers should correspond to files you have share-tied using
or should be an empty vector (meaning release all holds). The effect of
⎕FHOLD is as
Firstly any existing file-holds belonging to this APL task
are released. Secondly the system
attempts to secure an exclusive lock on all the file numbers you have specified
in the argument. Only one task can hold
a given file at any time. If any of the
files you try to hold are already held by another task, the operation waits
until all files are available.
All file holds are automatically released when the APLX task
reaches desk-calculator mode (this means you cannot experiment with
in desk-calculator mode), or when the APL task ends. For best performance in
multi-user or multi-tasking applications, you should attempt to minimize the
amount of time that your application holds files for exclusive use.
⎕FHOLD is protected against deadlock. Supposing Task 1 tries to lock files A and
B, and at the same time Task 2 tries to lock files B and A. You could get a situation where each task successfully locks the first file it tries, and then both tasks wait for ever
for the second to be unlocked. APLX detects this situation, and automatically corrects for it by backing off (i.e. releasing any locks), waiting a random period, and then trying again.
⎕FHOLD uses operating-system locks. Where you have files accessed over a
network, some network systems do not honor locks correctly, particularly when
mixing clients of different types (e.g. Windows and Linux tasks). We recommend testing the effect of
⎕FHOLD when implementing multi-user
or multi-tasking file-systems across networks.
⎕FHOLD may do nothing on some single-user
versions of APLX, for example APLX Personal Edition.