> On Apr 10, 2015, at 8:38 PM, Christian Rober <[email protected]> wrote: > > Nicely done sir!
Thanks :) > Yeah... the man page for pthread_rwlockatt_setspshared says that > PTHREAD_PROCESS_SHARED is not supported under the BUGS section (i'm on 10.9.5 > too). That's a shame. :( Ah, right — that would explain why I couldn’t get it to work. :( > I also could not find the man page for pthread_mutexattr_setspshared. After > a quick google search, it seems that the kernel may not REALLY implement that > function. You may not be getting the protection you expect, though I hope > you are! I tested it with a little torture test (where I have several processes locking the mutex, writing to the shared memory area, reading back what they wrote, then unlocking it again, in an endless loop). With the pthread_mutexattr_setpshared() call in place, the test proceeds as expected. If I comment out the pthread_mutexattr_setpshared() call, the processes all hang/deadlock as soon as I start the second one. So it appears that the call is functional and necessary. > One small thing, I think your 2nd call to open will return EEXIST if there is > a race and you lost to your other process. My understanding is that create > is "atomic", within kernel and with respect to the file descriptors. In a > create race condition one will fail and one will succeed (assuming all else > is sound). You may want to check errno in that case, but this race is > probably super rare, if it exists at all. You’re right, I will add some code to handle that possibility. Thanks! Jeremy _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
