mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: AK47 <250200715@qq.com>
Cc: musl <musl@lists.openwall.com>
Subject: Re: [musl] Re:Re: [musl] Pthread robust_list for non-pshared mutexes
Date: Fri, 24 May 2024 13:01:40 -0400	[thread overview]
Message-ID: <20240524170140.GD10433@brightrain.aerifal.cx> (raw)
In-Reply-To: <tencent_24E233C47719A30D8A6424D4C271E4351508@qq.com>

On Fri, May 24, 2024 at 10:43:05PM +0800, AK47 wrote:
> Hi,
> 
> 
> 
> Sorry, maybe what I asked was a bit confusing. My question is,
> except robust and process-shared mutex, &nbsp;what is the purpose of
> putting the other kinds of mutexes into Robust_list such as the
> normal recursive mutex.&nbsp;
> 
> 
> Take a normal recursive mutex as an example, if I lock and unlock it
> correctly in a thread, it will be put into robust list in
> pthread_mutex_lock and get removed from the list in
> pthread_mutex_unlock(). If I lock it but miss to unlock, it will be
> still in&nbsp;robust list and processed
> in&nbsp;pthread_exit().&nbsp;But in both cases, I did not find that
> the presence of the robust list had any impact on this mutex. Does
> it not need to be put into the robust list.

It is put in the list specifically so that, if the thread (or, in the
case of pshared, the entire process) holding the mutex exits, any
future attempt to take the mutex will deadlock. Otherwise, you have an
identifier-reuse bug whereby, if a new thread comes into existence and
gets the same thread-id that the exited thread had, it will wrongly
see itself as the owner of the mutex and succeed in taking a recursive
lock on it, instead of deadlocking like it should (and like POSIX
requires it to).

Rich

      reply	other threads:[~2024-05-24 17:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-24 14:43 AK47
2024-05-24 17:01 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240524170140.GD10433@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=250200715@qq.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).