Hi Corinna, On Mon, 24 Mar 2025 11:57:06 +0100 Corinna Vinschen wrote: > On Mar 24 14:53, Takashi Yano wrote: > > Previously, the fast_mutex defined in thread.h could not be aquired > > multiple times, i.e., the thread causes deadlock if it attempted to > > acquire a lock already acquired by the thread. For example, a deadlock > > occurs if another pthread_key_create() is called in the destructor > > specified in the previous pthread_key_create(). This is because the > > run_all_destructors() calls the desructor via keys.for_each() where > > both for_each() and pthread_key_create() (that calls List_insert()) > > attempt to acquire the lock. With this patch, the fast_mutex can be > > acquired multiple times by the same thread similar to the behaviour > > of a Windows mutex. In this implementation, the mutex is released > > only when the number of unlock() calls matches the number of lock() > > calls. > > Doesn't that mean fast_mutex is now the same thing as muto? The > muto type was recursive from the beginning. It's kind of weird > to maintain two lock types which are equivalent.
I have just looked at muto implementation. Yeah, it looks very similar to fast_mutex with this patch. However, the performance is different. fast_mutex with this patch is two times faster than muto when just repeatedly locking/unlocking. If two threads compete for the same mutex, the performance is almost the same. > I wonder if we shouldn't drop the keys list structure entirely, and > convert "keys" to a simple sequence number + destructor array, as in > GLibc. This allows lockless key operations and drop the entire list and > mutex overhead. The code would become dirt-easy, see > https://sourceware.org/cgit/glibc/tree/nptl/pthread_key_create.c > https://sourceware.org/cgit/glibc/tree/nptl/pthread_key_delete.c > > What do you think? It looks very simple and reasonable to me. > However, for 3.6.1, the below patch should be ok. What about reimplementing pthread_key_create/pthread_key_delete based on glibc for master branch, and appling this patch to cygwin-3_6-branch? Shall I try to reimplement them? -- Takashi Yano <takashi.y...@nifty.ne.jp>
