Return one-based key so that user can check if the key is ever allocated in the first place.
to be changed.
Reported by: dougb
------------------------------------------------------------------------ r238637 | davidxu | 2012-07-20 09:56:14 +0800 (Fri, 20 Jul 2012) | 6 lines Don't forget to release a thread reference count, replace _thr_ref_add() with _thr_find_thread(), so reference count is no longer needed. ------------------------------------------------------------------------ r238640 | davidxu | 2012-07-20 11:00:41 +0800 (Fri, 20 Jul 2012) | 2 lines Eliminate duplicated code. ------------------------------------------------------------------------ r238641 | davidxu | 2012-07-20 11:16:52 +0800 (Fri, 20 Jul 2012) | 2 lines Eliminate duplicated code. ------------------------------------------------------------------------ r238642 | davidxu | 2012-07-20 11:22:17 +0800 (Fri, 20 Jul 2012) | 2 lines Don't assign same value.
Set SIGCANCEL to SIGTHR as part of some cleanup of DTrace code. Reviewed by: davidxu@
Return EBUSY for PTHREAD_MUTEX_ADAPTIVE_NP too when the mutex could not be acquired. PR: 168317
On shared object unload, in __cxa_finalize, call and clear all installed atexit and __cxa_atexit handlers that are either installed by unloaded dso, or points to the functions provided by the dso. Use _rtld_addr_phdr to locate segment information from the address of private variable belonging to the dso, supplied by crtstuff.c. Provide utility function __elf_phdr_match_addr to do the match of address against dso executable segment. Call back into libthr from __cxa_finalize using weak __pthread_cxa_finalize symbol to remove any atfork handler which function points into unloaded object. The rtld needs private __pthread_cxa_finalize symbol to not require resolution of the weak undefined symbol at initialization time. This cannot work, since rtld is relocated before sym_zero is set up. MFC r211894: Do not call __pthread_cxa_finalize with invalid struct dl_phdr_info. Requested and tested by: Peter Jeremy <peter rulingia com>
233103: Some software think a mutex can be destroyed after it owned it, for example, it uses a serialization point like following: pthread_mutex_lock(&mutex); pthread_mutex_unlock(&mutex); pthread_mutex_destroy(&muetx); They think a previous lock holder should have already left the mutex and is no longer referencing it, so they destroy it. To be maximum compatible with such code, we use IA64 version to unlock the mutex in kernel, remove the two steps unlocking code. 233912: umtx operation UMTX_OP_MUTEX_WAKE has a side-effect that it accesses a mutex after a thread has unlocked it, it event writes data to the mutex memory to clear contention bit, there is a race that other threads can lock it and unlock it, then destroy it, so it should not write data to the mutex memory if there isn't any waiter. The new operation UMTX_OP_MUTEX_WAKE2 try to fix the problem. It requires thread library to clear the lock word entirely, then call the WAKE2 operation to check if there is any waiter in kernel, and try to wake up a thread, if necessary, the contention bit is set again by the operation. This also mitgates the chance that other threads find the contention bit and try to enter kernel to compete with each other to wake up sleeping thread, this is unnecessary. With this change, the mutex owner is no longer holding the mutex until it reaches a point where kernel umtx queue is locked, it releases the mutex as soon as possible. Performance is improved when the mutex is contensted heavily. On Intel i3-2310M, the runtime of a benchmark program is reduced from 26.87 seconds to 2.39 seconds, it even is better than UMTX_OP_MUTEX_WAKE which is deprecated now. http://people.freebsd.org/~davidxu/bench/mutex_perf.c Special code for stable/8: And add code to detect if the UMTX_OP_MUTEX_WAKE2 is available. PR: threads/167308
Some software think a mutex can be destroyed after it owned it, for example, it uses a serialization point like following: pthread_mutex_lock(&mutex); pthread_mutex_unlock(&mutex); pthread_mutex_destroy(&muetx); They think a previous lock holder should have already left the mutex and is no longer referencing it, so they destroy it. To be maximum compatible with such code, we use IA64 version to unlock the mutex in kernel, remove the two steps unlocking code.