On Wed, 26 Mar 2025 18:14:04 +0900 Takashi Yanowrote: > Hi Corinna, > > On Mon, 24 Mar 2025 16:35:08 +0100 > Corinna Vinschen wrote: > > On Mar 24 22:05, Takashi Yano wrote: > > > 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. > > > > Ok, nice to know. With fast_mutex being mostly faster and being > > recursive with your patch, maybe we could replace all mutos with > > this fast_mutex? > > > > > > 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? > > > > That would be great! > > What about the patch attached? > Is this as you intended?
Having a race issue between pthread_key_delete() and _fixup_befor_fork()/_fixup_after_fork()/run_all_destructors(). Let me consider again. -- Takashi Yano <takashi.y...@nifty.ne.jp>
