Correct memory ordering for atomic counter to check association between mutexes and condition variables

    // I used memoryorderacquire, to ensure CxingDebug is only called
    // after there are over-lived condition variables. Q is this correct?

Memory ordering is about which writes to other objects (atomic and non-atomic) by one thread must be visible to other threads. cvassoc is atomic, so even with relaxed memory order, all threads would observe all other threads' writes to this variable itself, and they would not be reordered with respect to other atomic operations or synchronization actions by the same thread (on the same variable).

With memoryorderacquire, if the thread executing cxingmutexfin() observes cxmtx->cvassoc to have value 0 then it will also subsequently observe the last writes to all other shared variables by the thread that wrote the 0 (with a release operation), or possibly other subsequent writes. But this does not seem important for cxingmutexfin() itself unless there is a risk that there has been a modification to the value of cxmtx->mtxproper that needs to be ensured observed. It may be relevant for this function's caller.

One other thing to note: nothing in cxingmutexfin() ensures that another thread does not increment cxmtx->cvassoc between execution of that function's atomicload() and its pthreaddestroy(). For robustness, you may want some kind of mutual exclusion to the contents of cxingmutext. You don't want to use the wrapped mutex itself for that, but you could consider a lightweight atomic spinlock. Your target platform might offer other good alternatives.