472 30.ACross‐PlatformMultithreadingFramework
we want to discuss is the possibility of a Mac OS X port. The source code pro-
vided on the website is basically ready to be built on a Mac, but there are a few
things to consider. The first one is that the Mac OS X kernel only supports a total
of 10 System V semaphores, using the
SEM_UNDO flag, in the whole system
[Huyler 2003]. This means that if no other application is using a System V sema-
phore, we can have a maximum of three named semaphores, mutexes, or events
with our framework on Mac OS X. A simple solution to this problem is to use
only POSIX semaphores for both named and unnamed synchronization objects
on Mac OS X platforms. However, a problem that is introduced by this fix is that
the named auto-reset event implementation in our framework requires the flexi-
bility of System V’s
semop() function. A POSIX implementation could be made
similar to the one for an unnamed event, but it has to keep the signal flag in a
shared memory segment. Another problem we experienced on Mac OS X was
that the
sem_init() function always failed with an ENOSYS error. This is because
the POSIX semaphores implementation on Mac OS X only supports named sem-
aphores and does not implement
sem_init() [Jew 2004]. Apart from these limi-
tations, the framework should already work perfectly on Mac OS X, without
requiring any code changes.
In this chapter, we also showed how to implement a wait function similar to
the Windows API
WaitForMultipleObjects() function. However, our imple-
mentation currently only works with unnamed events. This limitation is caused
by the condition variable used to signal that an object has been unlocked, which
is only visible to a single process. This means that if a named mutex is unlocked
in process A, our wait function in process B won’t be notified of the state change
and will remain blocked. A possible solution to this problem is to use a System V
semaphore to signal a state change across process boundaries. However, this
should be used with care since our processes might end up receiving many notifi-
cations, resulting in a lot of polling in the
WaitList. On Windows, you can also
specify whether you want to wait for any or all objects in the
WaitList. Our cur-
rent implementation only supports the first case, but adding support for the se-
cond case should be straightforward. Finally, if you are really concerned about
performance, you might want to add a
BasicWaitList class that works with the
basic synchronization classes, instead of
WaitObject-derived ones.
The last potential pitfall that we want to highlight occurs when using named
mutexes. On Windows, mutexes can be locked by the same thread multiple times
without blocking. With Pthreads, you can specify whether the mutex should be
recursive using the
PTHREAD_MUTEX_RECURSIVE type. Unfortunately, our imple-
mentation does not offer this functionality using our System V semaphore with-
out introducing additional overhead to keep track of the current thread and its