gh-154431: Use existing runtime->audit_hooks.mutex instead of a new one

[sobolevn]

• Issue: Data race: sys.addaudithook() lazily creates interp->audit_hooks with no lock #154431

[ZeroIntensity]

This will just increase contention in sys.addaudithook, won't it?

[sobolevn]

I don't think that we actually concurrenly add hooks with both PySys_AddAuditHook and sys.audithook, so realistically - it should not matter.

[ZeroIntensity]

Agreed, but why make this change at all? We're just increasing pressure on a lock for no reason. PyMutex is just a single byte; due to alignment, I would be surprised if you see any change in memory overhead.

[sobolevn]

Because we can't backport the fix with interpreter state changed due to ABI change.
And we want to fix the data race on 3.14 :(

[weixlu]

Hi, I noticed the mutex here is copied by value onto the stack, then being locked. I'm worried this subtly changes the semantics into locking a stack-local object instead. The typical usage may be to lock the address directly, i.e. PyMutex_Lock(&interp->runtime->audit_hooks.mutex);

[weixlu]

Here is a demo shows locking a stack-local mutex won't affect the real mutex.

#include <Python.h>
#include <stdio.h>

static PyMutex shared = {0};

int main(void)
{
    PyMutex mutex = shared;
    PyMutex_Lock(&mutex);
    printf("locked the COPY:  shared=%d copy=%d\n", PyMutex_IsLocked(&shared), PyMutex_IsLocked(&mutex));
    PyMutex_Unlock(&mutex);

    PyMutex_Lock(&shared);
    printf("locked the FIELD: shared=%d\n", PyMutex_IsLocked(&shared));
    PyMutex_Unlock(&shared);
    return 0;
}

Run gcc mutex_copy_demo.c -I Include -I . libpython3.16.a -lpthread -lm -ldl -lutil -o demo && ./demo then it print

locked the COPY:  shared=0 copy=1
locked the FIELD: shared=1