mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Re:Re: [musl] Pthread robust_list for non-pshared mutexes
@ 2024-05-24 14:43 AK47
  2024-05-24 17:01 ` Rich Felker
  0 siblings, 1 reply; 2+ messages in thread
From: AK47 @ 2024-05-24 14:43 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

Hi,



Sorry, maybe what I asked was a bit confusing. My question is, except robust and process-shared mutex,  what is the purpose of putting the other kinds of mutexes into Robust_list such as the normal recursive mutex. 


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 robust list and processed in pthread_exit(). 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.




Best Regards

JinCheng Li







                       
Original Email
                       
                     

Sender:"Markus Wichmann"< nullplan@gmx.net &gt;;

Sent Time:2024/5/24 21:58

To:"musl"< musl@lists.openwall.com &gt;;

Cc recipient:"AK47"< 250200715@qq.com &gt;;

Subject:Re: [musl] Pthread robust_list for non-pshared mutexes


Hi,

not entirely sure what you mean. All non-normal mutexes get added to the
robust list, yes, but also get removed from the list in
pthread_mutex_unlock(). And the robust list is processed in
pthread_exit(), which all threads must call sooner or later. Only
exception is when a thread crashes, but in that case the entire process
dies, and non-pshared mutexes cease to matter.

If a thread is cancelled, __cancel() will call pthread_exit(). And I
know of no other way for a thread to "end" as you put it.

Ciao,
Markus

[-- Attachment #2: Type: text/html, Size: 14741 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [musl] Re:Re: [musl] Pthread robust_list for non-pshared mutexes
  2024-05-24 14:43 [musl] Re:Re: [musl] Pthread robust_list for non-pshared mutexes AK47
@ 2024-05-24 17:01 ` Rich Felker
  0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2024-05-24 17:01 UTC (permalink / raw)
  To: AK47; +Cc: musl

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-05-24 17:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-24 14:43 [musl] Re:Re: [musl] Pthread robust_list for non-pshared mutexes AK47
2024-05-24 17:01 ` Rich Felker

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).