Note: this use case is available since flom version 0.1.4
Sometimes you need to manage shared locks instead of exclusive locks.
A typical scenario is the "multiple readers / single-writer lock": many processes can access a resource at the same time (because they does not modify the resource state) and only one process can access a resource to update it.
Much more interesting use cases can be implemented using the lock mode semantic proposed by VMS Distributed Lock Manager.
tiian@mojan:/usr$ flom --lock-mode=PR -- ls bin games include lib lib64 local sbin share src tiian@mojan:/usr$ echo $? 0 tiian@mojan:/usr$
tiian@mojan:~$ flom -- sleep 10 tiian@mojan:~/src/flom$ echo $? 0 tiian@mojan:~$
command "sleep 10" locks the default resource, but it specifies Protected Read (PR) as lock mode, command "ls" tries to lock the same resource using Protected Read lock mode and as explained in VMS DLM truth table, Protected Read lock mode allows resource sharing.
"ls" command is executed after terminal two terminated
The second terminal command uses Protected Read lock mode and can share the resource with someone else, but first terminal command uses (default) Exclusive lock mode and must wait the resource becomes free to lock it exclusively.
This use case explains you how to implement the "multiple readers / single-writer lock" pattern and gives you the tool to implement more complex patterns using the powerful semantic offered by flom lock manager because it implements the full lock mode semantic proposed by VMS DLM: "Null Lock", "Concurrent Read", "Concurrent Write", "Protected Read", "Protected Write", "Exclusive".
Flom available arguments are documented in man page: use man flom.
Flom [Configuration] explains how you can specify flom behavior without using command line arguments.
VMS Distributed Lock Manager is a good start point for understanding lock modes.