Make recursive mutexes faster

Recursive mutexes now go as fast as normal mutexes. The tradeoff is they
are no longer safe to use in signal handlers. However you can still have
signal safe mutexes if you set your mutex to both recursive and pshared.
You can also make functions that use recursive mutexes signal safe using
sigprocmask to ensure recursion doesn't happen due to any signal handler

The impact of this change is that, on Windows, many functions which edit
the file descriptor table rely on recursive mutexes, e.g. open(). If you
develop your app so it uses pread() and pwrite() then your app should go
very fast when performing a heavily multithreaded and contended workload

For example, when scaling to 40+ cores, *NSYNC mutexes can go as much as
1000x faster (in CPU time) than the naive recursive lock implementation.
Now recursive will use *NSYNC under the hood when it's possible to do so
This commit is contained in:
Justine Tunney 2024-09-09 22:07:03 -07:00
parent 58d252f3db
commit 2f48a02b44
No known key found for this signature in database
GPG key ID: BE714B4575D6E328
37 changed files with 2684 additions and 2209 deletions

View file

@ -8,7 +8,6 @@
#define PTHREAD_BARRIER_SERIAL_THREAD 31337
#define PTHREAD_MUTEX_DEFAULT 0
#define PTHREAD_MUTEX_NORMAL 0
#define PTHREAD_MUTEX_RECURSIVE 1
#define PTHREAD_MUTEX_ERRORCHECK 2
@ -77,6 +76,7 @@ typedef struct pthread_mutex_s {
};
/* this cleverly overlaps with NSYNC struct Dll *waiters; */
_PTHREAD_ATOMIC(uint64_t) _word;
long _nsyncx[2];
} pthread_mutex_t;
typedef struct pthread_mutexattr_s {
@ -95,6 +95,8 @@ typedef struct pthread_cond_s {
uint32_t _nsync;
char _pshared;
char _clock;
char _footek;
_PTHREAD_ATOMIC(char) _waited;
};
};
_PTHREAD_ATOMIC(uint32_t) _sequence;