[ntp:questions] new driver development

Bruce Lilly bruce.lilly at gmail.com
Mon Mar 28 04:39:41 UTC 2011

On Sat, 19 Mar 2011 22:06:16 -0500, Hal Murray wrote:

> In article <2wlgp.34776$d46.31874 at newsfe07.iad>,
>  Bruce Lilly <bruce.lilly at gmail.com> writes:
>> o POSIX mutex for synchronized access to shared memory for updates
>>   -- obviates mode 0 / mode 1 / OLDWAY
> I'm far from a POSIX wizard.  When I google for >POSIX mutex< I get a
> bunch of hits that all are part of pthreads.
> Does that stuff work across processes rather than threads?
> The mutex needs to be in shared memory so both processes can get at it.
> Right?  Who initializes it?

Mutexes can work across processes; look for pthread_mutexattr_setpshared.

The first party who needs the mutex (if not already initialized)
initializes it.  Destruction is another issue.

There are a lot of complications (e.g. the mutex (and its attributes)
typically are mapped to different addresses in different processes).

POSIX semaphores are a bit simpler to use, even though a semaphore is
more generic than a mutex.  And POSIX semaphores come in unnamed
(which can reside in shared memory) and named varieties. Unfortunately,
there are plenty of implementation issues.

In either (mutex/semaphore) case, there is a related issue; viz. it is
unclear whether or not either will work in cross-word-size situations
(i.e. on a 64-bit machine with both 64-bit and 32-bit libraries where
one process is built and linked for 32-bit and the other for 64-bit),
or worse (bi-endian machines).  About the best one can do is to
identify word size and byte order of both processes and refuse to
play if there's a mismatch.

I can avoid the word size and byte order issues entirely (though not
without some small performance cost), and avoid the need for a semaphore
or mutex as well using another IPC technology (and with a few additional
benefits).  But that's a story for another day.

More information about the questions mailing list