I ran into this problem recently on macOS 14.5. I came across this Stack Overflow post that describes a similar issue. One of the commenters there had a work-around where you can cast the pthread_cond_t to a type that exposes its internal implementation and manually set the busy field to NULL before calling pthread_cond_wait(). I was able to confirm that this works by testing the following code snippet. typedef struct { long sig; uint32_t lock; uint32_t unused; char *busy; } ndrx_osx_pthread_cond_t; ndrx_osx_pthread_cond_t *cond_ptr = (ndrx_osx_pthread_cond_t *)&cond; cond_ptr->busy = NULL; pthread_cond_wait(&cond, &mutex.mtx); According to the Stack Overflow post, another process will set busy to its mutex address, but because shmat() does not guarantee that addresses will be equal across processes, the values fail the equality check done in pthread_cond_wait(), causing it to return EINVAL. This seems like a hacky work-around, but it worked for me. Hope this helps.