Re: Shared pthread mutex and condition variables

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Fri, 15 Jan 2010 19:14:57 +0000
Sad Clouds <cryintothebluesky%googlemail.com@localhost> wrote:

> NetBSD is missing the following functions
> 
> pthread_mutexattr_setpshared()
> pthread_mutexattr_setpshared()
> pthread_condattr_setpshared()
> pthread_condattr_getpshared()
> 
> So I take it there is no way to have multiple unrelated processes to share 
> the 
> same mutex/condition variable?

I'm actually surprised by the existence of these; often a thread is
lighter than a process and inter-thread locks lighter than interprocess
locks/semaphores (often implemented without the need for a syscall)...
However with the currently popular 1:1 threading model where locks are
inter-LWP, perhaps that there's not much work to be done for them to be
able to also work among different processes...

For now, if you want inter-process locks on NetBSD the alternatives
are fcntl(2), flock(2), lockf(3), sem(4) or semctl(2)/semget(2)/semop(2).
For shared memory between processes there's mmap(2) (MAP_ANON is
especially nice on BSD as it doesn't require a file, yet one can also
map /dev/zero on several OSs), SysV shm, and POSIX shm_*.

Note: A good reference for various ways to use shared memory and locks
between processes can be found in Ralf S. Engelschall's libmm which is
also part of the apache runtime, and its excellent mm(3) manual page.
Depending on the system it's compiled on it'll prefer to use a method
or another taking in consideration availability and performance.

Since I initially wondered how to deal with situations where the shared
memory between processes had to grow over time, in case it can help
you, with experimentation I found that the simplest solution was for
the parent process to allocate a large region of shared memory at
startup but to only make use of what's necessary, which at least with
NetBSD UVM worked wonders for me.  Even though a large region is
mapped by the VM, only pages which are accessed actually get allocated
(assuming they're not wired), and children can inherit those at fork(2).

Temporary files or SysV shm/sem proved useful when many instances of a
short-running program (not necessarily started by the parent process)
needed to attach/detach to existing shared resources (generally
maintained by a longer running daemon).
-- 
Matt