ID Number: Q66473
2.00
OS/2
Question:
I have two programs that try to lock/unlock a file locally or over a
network. Program 1 (Writer) opens a file for read/write access, with
no other writers allowed. It locks the file, writes out some data, and
then unlocks the file.
Program 2 (Reader) opens this same file for read-only access. It
locks the file, reads in some consistent data, and then unlocks the
file.
Suppose the Writer program has the file locked, and the Reader program
wants to read this same file. The Reader program tries to lock the
file, but this fails because the Writer program has already locked the
file. The Reader program delays for a little while, and then tries to
lock the file again. Eventually, the Writer program will finish
writing and will unlock the file. The next time the Reader program
tries to lock the file, the lock will succeed.
This works correctly with local disk files, but doesn't work correctly
for files that reside on a remote server. Once the Reader program gets
a lock violation error on a remote file, all subsequent attempts to
lock the file fail with the same error, even after the Writer program
unlocks the file. In fact, the Reader program can't lock the file
until the Writer program closes the file.
The following output is produced when a third program is run that has
two threads in it. Thread 1 simulates access by the Writer (program 1)
program, and thread 2 simulates access by the Reader (program 1)
program. The threads try to lock a file named "testfile". Thread 1
unlocks the file after some time, so that thread 2 can lock the file.
The output listed below occurs when "testfile" resides on a local
disk:
Thread 1: File open
Thread 1: File locked
Thread 2: File open
Unable to do lock #2: testfile, error 33
Unable to do lock #2: testfile, error 33
Unable to do lock #2: testfile, error 33
...
Thread 1: File unlocked
Thread 2: File locked
Thread 2: File unlocked
Thread 2: File closed
Thread 1: File closed
If you run this same program with "testfile" residing on a remote
disk, you get the following output:
Thread 1: File open
Thread 1: File locked
Thread 2: File open
Unable to do lock #2: testfile, error 33
Unable to do lock #2: testfile, error 33
Unable to do lock #2: testfile, error 33
...
Thread 1: File unlocked
Unable to do lock #2: testfile, error 33
Unable to do lock #2: testfile, error 33
Unable to do lock #2: testfile, error 33
...
Thread 1: File closed
Thread 2: File locked
Thread 2: File unlocked
Thread 2: File closed
Please note that the lock attempt in thread 2 (the Reader program)
fails even after the Writer program unlocks the file. In fact, the
lock attempt by the Reader program doesn't succeed until the Writer
program closes the file.
Response:
This behavior is not considered to be a problem with the OS/2 LAN
Manager. This behavior is an optimization being performed at the
workstation end. If a file has been opened in Deny-Write mode, by
default, the workstation will buffer I/O on that handle similar to
Deny-None or an OpLocked file. This normally can be done because the
workstation knows that the contents of the file cannot change. In some
cases, the buffering of a Deny-Write file handle can cause a problem
(normally with Locking and Unlocking requests). The wrkheuristic
number 23 can be used to turn off buffering for Deny-Write file
handles.