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!


Thanks,
Corinna

Reply via email to