Thread: shared memory: how to synchronize exchanging pthread_mutex and pthread_condition?

Hi All, I am writing a shared memory application in which two processes A and B communicate over shared memory. Process B is NOT a forked process from A. The issue I'm having is the following:

A is the creator of the segment. A will call shm_open, ftruncate(size), mmap(size). size is the size of pthread_cond_t and pthread_mutex_t. From this mmap'd segment, A uses this memory to create a mutex and a lock.

B then starts, does shm_open and loops until this returns a fd that's not -1. It then mmaps for the same size (pthread_cond_t + pthread_mutex_t), and then keeps a reference to that mmap'd memory at the right offset for the cond and mutex.

This works literally 99% of the time. However, SOME TIMES, B segfaults when trying to use the lock. It will be on the first reference to the lock and I assume that this is a race condition.

How am I supposed to synchronize this initial condition? I've tried using a "dummy" file.. A will do all the stuff to create the shared memory segment, mutex, cond, etc, and then it will call shm_open ("dummy_file..."

B then, before trying to read the mutex and cond, will loop shm_open on "dummy_file". Once it sucessfully open's dummy file, it will then shm_open, mmap, read from the other file/segment containing the actual data.

This doesn't seem to work. Using semaphores won't work either as I have to copy that semaphore into the shared memory segment and I end up with the same stuff.

What am I missing?

The error I am getting is SIGBUS, but it doesn't make sense. I can ftruncate the file to something larger than the mutex + cond (i.e., getpagesize()) and I can even do msync(...MS_SYNC) and it still fails at the same spot!

I have NO IDEA why this is doing this.

Should I try to produce a minimal version of the bug? Or is this a familiar problem and I'm just missing something?

I have solved the problem. Basically, there is an inherent race condition here. shm_open, ftruncate, mmap, setup mutex/cond.

The reading application, i.e., applicaiton B, can start to access the shared memory segment right after A's shm_open. If this happens before A does an ftruncate, then it all blows up. I am now having B use fstat to wait until the size of the file (shared memory segment) is the right size.