[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