I just read this page of the Boost.Interprocess documentation. It seems to suggest that in order to accommodate the differences among different operating systems and come to some agreement, certain interprocess mechanisms are not implemented with the directly corresponding native mechanism provided by the operating system, but instead emulated using other mechanisms. I'm wondering whether this may impose a considerable performance hit.
The last section on that page is particularly concerning to me, which is cited below
Since each mechanism can be emulated through diferent mechanisms (a semaphore might be implement using mapped files or native semaphores) permissions types could vary when the implementation of a named resource changes (eg.: in Windows mutexes require synchronize permissions, but that's not the case of files). To avoid this, Boost.Interprocess relies on file-like permissions, requiring file read-write-delete permissions to open named synchronization mechanisms (mutex, semaphores, etc.) and appropiate read or read-write-delete permissions for shared memory. This approach has two advantages: it's similar to the UNIX philosophy and the programmer does not need to know how the named resource is implemented.
Based on this text, I'm guessing that most of the kernel objects provided natively by Windows for interprocess synchronization (e.g, Event, Mutex, Semaphore) are just not used by Boost.Interprocess.
