[PATCH] Cygwin: thread: Allow fast_mutex to be acquired multiple times.

[Takashi Yano]

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.yano@nifty.ne.jp>