The following program fails with illegal instruction on x86_64 on HW where _xend() is not supported (even if it would the behaviour is not probably correct): $ cat foo.c #include <pthread.h> #include <stdio.h> int main(void) { pthread_rwlock_t _lock; pthread_rwlock_init(&_lock, 0); pthread_rwlock_wrlock(&_lock); pthread_rwlock_unlock(&_lock); pthread_rwlock_unlock(&_lock); pthread_rwlock_destroy(&_lock); return 0; } $ gcc foo.c -lpthread $ ./a.out Illegal instruction This is caused by __pthread_rwlock_unlock() -> ELIDE_UNLOCK() -> _xend()
This test case is invalid. Calling pthread_rwlock_unlock on an rwlock which is not locked is undefined.
Ok, such programs can be considered broken. I was also pointed a workaround if you still need to run such: https://github.com/andikleen/tsx-tools/blob/master/ignore-xend.c
Yes don't do that as it's undefined. In theory it would be possible to put a workaround into glibc for it, but it would make the unlock path slower and so far it was not deemed needed for this undefined case.
Manual page for pthread_rwlock_unlock says: [...]If an implementation detects that the value specified by the rwlock argument to pthread_rwlock_unlock() refers to a read-write lock object for which the current thread does not hold a lock, it is recommended that the function should fail and report an [EPERM] error. So at least the current implementation does not follow the standard recommendation. Same applies for pthread_rwlock_rdlock() and then twice calling pthread_rwlock_unlock() - program will SIGSEGV (in my case).
It does follow, by not trying to detect the undefined situation.