System-wide global variable / semaphore / mutex in C++/Linux?
You can use a named semaphore if you can get all the processes to agree on a common name.
A named semaphore is identified by a name of the form
/somename
; that is, a null-terminated string of up to NAME_MAX-4 (i.e., 251) characters consisting of an initial slash, followed by one or more characters, none of which are slashes. Two processes can operate on the same named semaphore by passing the same name tosem_open(3)
.
For interprocess mutual exclusion, you can use file locking. With linux, the code is as simple as protecting the critical section with a call to flock
.
int fd_lock = open(LOCK_FILE, O_CREAT);flock(fd_lock, LOCK_EX);// do stuffflock(fd_lock, LOCK_UN);
If you need POSIX compatibility, you can use fcntl
.
You can make C++ mutexes work across process boundaries on Linux. However, there's some black magic involved which makes it less appropriate for production code.
Explanation:
The standard library's std::mutex
and std::shared_mutex
use pthread's struct pthread_mutex_s
and pthread_rwlock_t
under the hood. The native_handle()
method returns a pointer to one of these structures.
The drawback is that certain details are abstracted out of the standard library and defaulted in the implementation. For example, std::shared_mutex
creates its underlying pthread_rwlock_t
structure by passing NULL
as the second parameter to pthread_rwlock_init()
. This is supposed to be a pointer to a pthread_rwlockattr_t
structure containing an attribute which determines sharing policy.
public: __shared_mutex_pthread() { int __ret = pthread_rwlock_init(&_M_rwlock, NULL); ...
In theory, it should receive default attributes. According to the man pages for pthread_rwlockattr_getpshared()
:
The default value of the process-shared attribute is PTHREAD_PROCESS_PRIVATE.
That said, both std::shared_mutex
and std::mutex
work across processes anyway. I'm using Clang 6.0.1 (x86_64-unknown-linux-gnu / POSIX thread model). Here's a description of what I did to check:
Create a shared memory region with
shm_open
.Check the size of the region with
fstat
to determine ownership. If.st_size
is zero, thenftruncate()
it and the caller knows that it is the region's creating process.Call
mmap
on it.- The creator process uses placement-
new
to construct astd::mutex
orstd::shared_mutex
object within the shared region. - Later processes use
reinterpret_cast<>()
to obtain a typed pointer to the same object.
- The creator process uses placement-
The processes now loop on calling
trylock()
andunlock()
at intervals. You can see them blocking one another usingprintf()
before and aftertrylock()
and beforeunlock()
.
Extra detail: I was interested in whether the c++ headers or the pthreads implementation were at fault, so I dug into pthread_rwlock_arch_t
. You'll find a __shared
attribute which is zero and a __flags
attribute which is also zero for the field denoted by __PTHREAD_RWLOCK_INT_FLAGS_SHARED
. So it seems that by default this structure is not intended to be shared, though it seems to provide this facility anyway (as of July 2019).
Summary
It seems to work, though somewhat by chance. I would advise caution in writing production software that works contrary to documentation.