How to lock files using fcntl() and to work between threads of the same process

[mistretzu]

I'm a Windows C++ programmer and recently I started to work on Linux.

I need to look a file and for this I'm using fcntl() function like in the sample bellow.
fcntl() locks are taken into consideration only by other process.

    #include <stdio.h>
    #include <stdlib.h>
    #include <errno.h>
    #include <fcntl.h>
    #include <unistd.h>
    
    int main(int argc, char *argv[])
    {
    	/* l_type   l_whence  l_start  l_len  l_pid   */
    	struct flock fl = { F_WRLCK, SEEK_SET, 0,       0,     0 };
    	int fd;
    
        fl.l_pid = getpid();
    
    	if (argc > 1) 
    		fl.l_type = F_RDLCK;
    
    	if ((fd = open("lockdemo.c", O_RDWR)) == -1) {
    		perror("open");
    		exit(1);
    	}
    
    	printf("Press <RETURN> to try to get lock: ");
    	getchar();
    	printf("Trying to get lock...");
    
    	if (fcntl(fd, F_SETLKW, &fl) == -1) {
    		perror("fcntl");
    		exit(1);
    	}
    
    	printf("got lock\n");
    	printf("Press <RETURN> to release lock: ");
    	getchar();
    
    	fl.l_type = F_UNLCK;  /* set to unlock same region */
    
    	if (fcntl(fd, F_SETLK, &fl) == -1) {
    		perror("fcntl");
    		exit(1);
    	}
    
    	printf("Unlocked.\n");
    
    	close(fd);
    }

If I acquire a exclusive lock on a file from thread A, thread B will also succeed in obtaining an exclusive lock on the same file.
How can I make thread B to detect that the specified file is already locked?

[wje_lf]

How can I make thread B to detect that the specified file is already locked?

You can't. But you don't need to. There's another way.

Wrap a function around your attempt to lock the file. In this function, maintain a switch, locked with a mutex and condition variable in the normal manner, which shows whether any thread in this process is already waiting to lock the file. When this thread sees (inside the critical section of code) that no thread is trying to lock the file, set the switch and try to lock the file. You don't need to stay in the critical section of code when you actually lock the file, because this thread has already (been the only thread to) set that switch. But it doesn't hurt if you do stay in the critical section of code when you lock the file, because in either case other threads trying to lock the file will be blocked. For a slightly different reason, but blocked nonetheless.

Later, when releasing the lock, also reset the switch and do a pthread_cond_signal() in the normal manner to let some other thread have a crack at the lock.

Some operating systems implement POSIX threads as separate processes; in such environment, you wouldn't have had this problem. But others, like Linux, don't. If you jump through the hoops I just described, that code should work equally on both kinds of operating systems.

Hope this helps.

[mistretzu]

I see.

And I guess this approach will also work if I have a situation where process A with n threads runing on machine M1 and process B with m threads on machine M2 trying to work (lock) the file from machine M3 on NFS.

[wje_lf]

Yep.

The message you have entered is too short.  Please lengthen your
message to at least 10 characters.


+-----------------+
| OK, FINE! FINE! |
+-----------------+