From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id EF595246DF for ; Fri, 24 May 2024 19:01:32 +0200 (CEST) Received: (qmail 26122 invoked by uid 550); 24 May 2024 17:01:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26071 invoked from network); 24 May 2024 17:01:26 -0000 Date: Fri, 24 May 2024 13:01:40 -0400 From: Rich Felker To: AK47 <250200715@qq.com> Cc: musl Message-ID: <20240524170140.GD10433@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re:Re: [musl] Pthread robust_list for non-pshared mutexes 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,  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. 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