fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-06-01 09:01:40 +00:00
Code Issues Projects Releases Wiki Activity
musl/src/thread/pthread_mutex_unlock.c

32 lines
738 B
C
Raw Normal View History

initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
#include "pthread_impl.h"
int pthread_mutex_unlock(pthread_mutex_t *m)
{
implement robust mutexes some of this code should be cleaned up, e.g. using macros for some of the bit flags, masks, etc. nonetheless, the code is believed to be working and correct at this point.
2011-03-17 20:41:37 -04:00
pthread_t self;
avoid accessing mutex memory after atomic unlock this change is needed to fix a race condition and ensure that it's possible to unlock and destroy or unmap the mutex as soon as pthread_mutex_lock succeeds. POSIX explicitly gives such an example in the rationale and requires an implementation to allow such usage.
2011-08-02 20:31:15 -04:00
int waiters = m->_m_waiters;
int cont;
implement robust mutexes some of this code should be cleaned up, e.g. using macros for some of the bit flags, masks, etc. nonetheless, the code is believed to be working and correct at this point.
2011-03-17 20:41:37 -04:00
fix and optimize non-default-type mutex behavior problem 1: mutex type from the attribute was being ignored by pthread_mutex_init, so recursive/errorchecking mutexes were never being used at all. problem 2: ownership of recursive mutexes was not being enforced at unlock time.
2011-03-08 03:41:05 -05:00
if (m->_m_type != PTHREAD_MUTEX_NORMAL) {
avoid crash on stupid but allowable usage of pthread_mutex_unlock unlocking an unlocked mutex is not UB for robust or error-checking mutexes, so we must avoid calling __pthread_self (which might crash due to lack of thread-register initialization) until after checking that the mutex is locked.
2011-03-30 10:32:45 -04:00
if (!m->_m_lock)
return EPERM;
implement robust mutexes some of this code should be cleaned up, e.g. using macros for some of the bit flags, masks, etc. nonetheless, the code is believed to be working and correct at this point.
2011-03-17 20:41:37 -04:00
self = __pthread_self();
if ((m->_m_lock&0x1fffffff) != self->tid)
avoid crash on stupid but allowable usage of pthread_mutex_unlock unlocking an unlocked mutex is not UB for robust or error-checking mutexes, so we must avoid calling __pthread_self (which might crash due to lack of thread-register initialization) until after checking that the mutex is locked.
2011-03-30 10:32:45 -04:00
return EPERM;
implement robust mutexes some of this code should be cleaned up, e.g. using macros for some of the bit flags, masks, etc. nonetheless, the code is believed to be working and correct at this point.
2011-03-17 20:41:37 -04:00
if ((m->_m_type&3) == PTHREAD_MUTEX_RECURSIVE && --m->_m_count)
fix and optimize non-default-type mutex behavior problem 1: mutex type from the attribute was being ignored by pthread_mutex_init, so recursive/errorchecking mutexes were never being used at all. problem 2: ownership of recursive mutexes was not being enforced at unlock time.
2011-03-08 03:41:05 -05:00
return 0;
implement robust mutexes some of this code should be cleaned up, e.g. using macros for some of the bit flags, masks, etc. nonetheless, the code is believed to be working and correct at this point.
2011-03-17 20:41:37 -04:00
if (m->_m_type >= 4) {
self->robust_list.pending = &m->_m_next;
*(void **)m->_m_prev = m->_m_next;
if (m->_m_next) ((void **)m->_m_next)[-1] = m->_m_prev;
avoid accessing mutex memory after atomic unlock this change is needed to fix a race condition and ensure that it's possible to unlock and destroy or unmap the mutex as soon as pthread_mutex_lock succeeds. POSIX explicitly gives such an example in the rationale and requires an implementation to allow such usage.
2011-08-02 20:31:15 -04:00
cont = a_swap(&m->_m_lock, 0);
streamline mutex unlock to remove a useless branch, use a_store to unlock this roughly halves the cost of pthread_mutex_unlock, at least for non-robust, normal-type mutexes. the a_store change is in preparation for future support of archs which require a memory barrier or special atomic store operation, and also should prevent the possibility of the compiler misordering writes.
2011-03-30 09:06:00 -04:00
self->robust_list.pending = 0;
avoid accessing mutex memory after atomic unlock this change is needed to fix a race condition and ensure that it's possible to unlock and destroy or unmap the mutex as soon as pthread_mutex_lock succeeds. POSIX explicitly gives such an example in the rationale and requires an implementation to allow such usage.
2011-08-02 20:31:15 -04:00
goto wake;
implement robust mutexes some of this code should be cleaned up, e.g. using macros for some of the bit flags, masks, etc. nonetheless, the code is believed to be working and correct at this point.
2011-03-17 20:41:37 -04:00
}
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
}
avoid accessing mutex memory after atomic unlock this change is needed to fix a race condition and ensure that it's possible to unlock and destroy or unmap the mutex as soon as pthread_mutex_lock succeeds. POSIX explicitly gives such an example in the rationale and requires an implementation to allow such usage.
2011-08-02 20:31:15 -04:00
cont = a_swap(&m->_m_lock, 0);
wake:
if (waiters || cont<0)
__wake(&m->_m_lock, 1, 0);
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
return 0;
}
Reference in New Issue Copy Permalink