From owner-freebsd-threads@FreeBSD.ORG Mon May 12 18:11:26 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EDCB37B401; Mon, 12 May 2003 18:11:26 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id B946343FA3; Mon, 12 May 2003 18:11:25 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc01) with ESMTP id <20030513011124001003f26de>; Tue, 13 May 2003 01:11:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA95187; Mon, 12 May 2003 18:11:23 -0700 (PDT) Date: Mon, 12 May 2003 18:11:21 -0700 (PDT) From: Julian Elischer To: Peter Wemm , John Baldwin , threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Multiplexed threads signals. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 01:11:27 -0000 I'm looking at trying to work out who is to deliver a signal in an M:N process. We never answered some of these questions.. Altering ht ecode I find that I need to answer them now.. This started off as a comment in the code but it kept growing... better to discuss it... /* Here we need to decide our policy * with respect to waking up threads for async signal * delivery. Generally in this library, async signals are not * actually delivered to teh process, but rather a notification is * delivered during an upcall with a mask similar to that * used in the sigpending() call, and the library 'fetches' * the waiting signal using sigwait(); (0) - threads in sigwait for the signal get first crack. (1) * Firstly, if we interrupted a thread in userland, * don't wake up ANY kernel threads, When we finish * it's going back. It can take the signal with it.. * SYNC signals take this path, but do not create upcalls. * Async signals only do this if there is an upcall possible. I think that is probably ok.. Only async calls proceed beyond here. (2) * Secondly we will look for an idle upcall * and make it do an upcall. Better to bring up * another upcall than to interrupt a thread that * may not deserve being interrupted. Not really a problem. (3) * If there is a thread runnable that is going * to return to userland upon resumption * (i.e. been pre-empted). Set its bit and * let it handle it. Maybe give it a boost * if its low priority. If several, choose * highest priority. Don't do this if an upcall * is not possible, for that thread. * An actual upcall thread takes priority. Existing code will force this to convert to an upcall on transition to userland. (4) * If there is a thread actually running NOW * on another CPU and in userland, whack it * with an IPI and leave the rest to it. * We can not tell if it will create an upcall * on getting whacked since we can't look at it's * upcall mailbox. This results in option (1) for the other thread. But if it's in the UTS, no upcall will result. If this happens we are left with an un-notified signal, but at least we know that there will be at least one thread coming down eventually. if a process decides to run in purely non-upcall mode, then we can not deliver any async signals to it.. This could be a problem. This suggests that we need a way to deliver signals without the complicity of the UTS. Maybe if the next upgoing thread is not capable of doing an upcall, we just deliver on the stack as per normal. * To some extent * this suggests that we look for pending signals * when ENTERING the kernel for a syscall. One could * make the point that it MIGHT have received a clock * interrupt 1 instraction before enterring the syscall, * and then continued on to do the syscall. * This would be akin to returning an ERESTART * but before actually doing the meat of the syscall. Peter suggested that we keep a per-KSEGRP mask (lazily set) and that if we encounter a ksegrp with a signal unmasked and registered as not multiplexing, we just deliver up to it as on its stack.. (i.e. system scop threads just get signals as per normal) this coincides with what libthr does in the degenerate case. Julian From owner-freebsd-threads@FreeBSD.ORG Mon May 12 19:34:13 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 307A237B401; Mon, 12 May 2003 19:34:13 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 650C543F75; Mon, 12 May 2003 19:34:12 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4D2Y1Bg010697; Mon, 12 May 2003 22:34:01 -0400 (EDT) Received: from localhost (eischen@localhost)h4D2Y0jx010673; Mon, 12 May 2003 22:34:00 -0400 (EDT) Date: Mon, 12 May 2003 22:34:00 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: John Baldwin Subject: Re: Multiplexed threads signals. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 02:34:13 -0000 On Mon, 12 May 2003, Julian Elischer wrote: > > I'm looking at trying to work out who is to deliver a signal in an M:N > process. We never answered some of these questions.. Altering ht ecode I > find that I need to answer them now.. > > > This started off as a comment in the code but it kept growing... > > better to discuss it... > > /* Here we need to decide our policy > * with respect to waking up threads for async signal > * delivery. Generally in this library, async signals are not > * actually delivered to teh process, but rather a notification is > * delivered during an upcall with a mask similar to that > * used in the sigpending() call, and the library 'fetches' > * the waiting signal using sigwait(); I was think about the _kernel_'s sigwait/sigwaitinfo/sigtimedwaitinfo(). If the UTS allocated a separate thread whose only job was to receive signals using sig[timed]wait[info]() and dispatch them to other threads would this make things easier? This would be only for async signals; sync signals would still be delivered as they would for a normal thread/process. Or perhaps some new syscall (_kse_sigtimedwait())... The only thing that the UTS would need is to be able to redirect the signal to a thread running or blocked in the kernel or a scope process thread that has no upcall stack (assuming we add this optimization at some point). The only problem is telling the kernel that we actually found a thread to handle the signal. Perhaps sigsuspend() is better to use, and then we can retrieve it using sigwaitinfo(). The kernel needs to know that the UTS has a thread for the signal so it can remove it from the pending signals and also allow a sender using sigqueue() to wakeup. > (0) - threads in sigwait for the signal get first crack. > > (1) * Firstly, if we interrupted a thread in userland, > * don't wake up ANY kernel threads, When we finish > * it's going back. It can take the signal with it.. > * SYNC signals take this path, but do not create upcalls. > * Async signals only do this if there is an upcall possible. > > I think that is probably ok.. > Only async calls proceed beyond here. > > (2) * Secondly we will look for an idle upcall > * and make it do an upcall. Better to bring up > * another upcall than to interrupt a thread that > * may not deserve being interrupted. > > Not really a problem. > > (3) * If there is a thread runnable that is going > * to return to userland upon resumption > * (i.e. been pre-empted). Set its bit and > * let it handle it. Maybe give it a boost > * if its low priority. If several, choose > * highest priority. Don't do this if an upcall > * is not possible, for that thread. > * An actual upcall thread takes priority. > > Existing code will force this to convert to an upcall > on transition to userland. > > (4) * If there is a thread actually running NOW > * on another CPU and in userland, whack it > * with an IPI and leave the rest to it. > * We can not tell if it will create an upcall > * on getting whacked since we can't look at it's > * upcall mailbox. Is there a need to whack it, or can we just wait until it (or another thread) enters the kernel again or gets swapped out and restarted? > This results in option (1) for the other thread. > But if it's in the UTS, no upcall will result. > If this happens we are left with an un-notified signal, but > at least we know that there will be at least one thread coming down > eventually. if a process decides to run in purely non-upcall mode, > then we can not deliver any async signals to it.. This could be a > problem. This suggests that we need a way to deliver signals without > the complicity of the UTS. Maybe if the next upgoing thread > is not capable of doing an upcall, we just deliver on the stack as per > normal. In libpthread, there can always be one KSE with upcalls if we so choose it. Even if we are emulating libthr, I don't see the harm in creating one extra KSE just for this purpose... > * To some extent > * this suggests that we look for pending signals > * when ENTERING the kernel for a syscall. One could > * make the point that it MIGHT have received a clock > * interrupt 1 instraction before enterring the syscall, > * and then continued on to do the syscall. > * This would be akin to returning an ERESTART > * but before actually doing the meat of the syscall. > > Peter suggested that we keep a per-KSEGRP mask > (lazily set) and that if we encounter a ksegrp with a signal > unmasked and registered as not multiplexing, we just deliver up to it as > on its stack.. (i.e. system scop threads just get signals as per normal) > this coincides with what libthr does in the degenerate case. Don't forget we still need a way to redirect signals. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon May 12 22:03:10 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E2FC37B404; Mon, 12 May 2003 22:03:10 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E3C43FD7; Mon, 12 May 2003 22:03:10 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h4D533Up007715; Mon, 12 May 2003 22:03:05 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <00c001c3190d$412d8f80$f001a8c0@davidw2k> From: "David Xu" To: "Julian Elischer" , "Peter Wemm" , "John Baldwin" , References: Date: Tue, 13 May 2003 13:05:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: Re: Multiplexed threads signals. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 05:03:11 -0000 I think we should implement single and not upcall enabled thread group now(system scope thread), because this kind of thread can=20 always be identified by kernel, so unlike multiplexed group, we can always redirect signal to that thread in kernel. in libpthread, creating one or more dedicated signal thread to receive async signals, these threads can use sigwaitinfo syscall to retrieve any async signals, these threads also redirect signals to threads in userland which are multiplexed, or, if posssible, these threads can also handle signals in userland directly without need to redirect signals to other threads.=20 whenever other processes or current process want to deliver async signals to the KSE process, one of those system scope threads is selected to delivering signal, td_sigmask can be used if a system scope thread does want to receive a signal at that time, if none of such system scope threads wants to receive signals, queue signal in process siglist, until some of them want to receive signal again. sync-signals are delivered as normal thread/process. I think most code are already in kernel. David Xu ----- Original Message -----=20 From: "Julian Elischer" To: "Peter Wemm" ; "John Baldwin" ; = Sent: Tuesday, May 13, 2003 9:11 AM Subject: Multiplexed threads signals. >=20 > I'm looking at trying to work out who is to deliver a signal in an M:N > process. We never answered some of these questions.. Altering ht ecode = I > find that I need to answer them now.. >=20 >=20 > This started off as a comment in the code but it kept growing... >=20 > better to discuss it... >=20 > /* Here we need to decide our policy > * with respect to waking up threads for async signal > * delivery. Generally in this library, async signals are not > * actually delivered to teh process, but rather a notification is = > * delivered during an upcall with a mask similar to that=20 > * used in the sigpending() call, and the library 'fetches'=20 > * the waiting signal using sigwait(); >=20 > (0) - threads in sigwait for the signal get first crack. >=20 > (1) * Firstly, if we interrupted a thread in userland, > * don't wake up ANY kernel threads, When we finish=20 > * it's going back. It can take the signal with it.. > * SYNC signals take this path, but do not create upcalls. > * Async signals only do this if there is an upcall possible. >=20 > I think that is probably ok.. > Only async calls proceed beyond here. >=20 > (2) * Secondly we will look for an idle upcall > * and make it do an upcall. Better to bring up > * another upcall than to interrupt a thread that > * may not deserve being interrupted. >=20 > Not really a problem. > =20 > (3) * If there is a thread runnable that is going > * to return to userland upon resumption > * (i.e. been pre-empted). Set its bit and > * let it handle it. Maybe give it a boost > * if its low priority. If several, choose > * highest priority. Don't do this if an upcall > * is not possible, for that thread. > * An actual upcall thread takes priority. >=20 > Existing code will force this to convert to an upcall > on transition to userland. >=20 > (4) * If there is a thread actually running NOW > * on another CPU and in userland, whack it > * with an IPI and leave the rest to it. > * We can not tell if it will create an upcall > * on getting whacked since we can't look at it's > * upcall mailbox. >=20 > This results in option (1) for the other thread. > But if it's in the UTS, no upcall will result. > If this happens we are left with an un-notified signal, but > at least we know that there will be at least one thread coming down > eventually. if a process decides to run in purely non-upcall mode, > then we can not deliver any async signals to it.. This could be a > problem. This suggests that we need a way to deliver signals without > the complicity of the UTS. Maybe if the next upgoing thread > is not capable of doing an upcall, we just deliver on the stack as per > normal. >=20 > * To some extent > * this suggests that we look for pending signals > * when ENTERING the kernel for a syscall. One could > * make the point that it MIGHT have received a clock > * interrupt 1 instraction before enterring the syscall, > * and then continued on to do the syscall. > * This would be akin to returning an ERESTART > * but before actually doing the meat of the syscall. >=20 > Peter suggested that we keep a per-KSEGRP mask > (lazily set) and that if we encounter a ksegrp with a signal > unmasked and registered as not multiplexing, we just deliver up to it = as > on its stack.. (i.e. system scop threads just get signals as per = normal) > this coincides with what libthr does in the degenerate case. >=20 > Julian >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to = "freebsd-threads-unsubscribe@freebsd.org" >=20 From owner-freebsd-threads@FreeBSD.ORG Tue May 13 01:26:43 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC0FB37B401 for ; Tue, 13 May 2003 01:26:43 -0700 (PDT) Received: from hotmail.com (bay2-dav11.bay2.hotmail.com [65.54.246.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9347E43F93 for ; Tue, 13 May 2003 01:26:43 -0700 (PDT) (envelope-from dsnofe@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 May 2003 01:26:43 -0700 Received: from 202.199.66.11 by bay2-dav11.bay2.hotmail.com with DAV; Tue, 13 May 2003 08:26:43 +0000 X-Originating-IP: [202.199.66.11] X-Originating-Email: [dsnofe@hotmail.com] Date: Tue, 13 May 2003 16:28:03 +0800 From: Snofe Deng To: freebsd-threads@freebsd.org Message-Id: <20030513162733.52E8.DSNOFE@hotmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.10 X-OriginalArrivalTime: 13 May 2003 08:26:43.0506 (UTC) FILETIME=[62991920:01C31929] Subject: where is mutexattr_setpshared()? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 08:26:44 -0000 As the title. I find it at pthread.h( cvs version 1.20) But now, it is not there. then how can I set the mutex with PTHREAD_PROCESS_SHARED?? use pthread_rwlockattr_setpshared(pthread_rwlockattr_t *, int) ????????? my box is 4.8R -- Snofe Deng From owner-freebsd-threads@FreeBSD.ORG Thu May 15 20:44:22 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DC4637B401 for ; Thu, 15 May 2003 20:44:22 -0700 (PDT) Received: from titan.kgt.co.jp (titan.kgt.co.jp [210.141.246.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6413C43F93 for ; Thu, 15 May 2003 20:44:21 -0700 (PDT) (envelope-from haro@kgt.co.jp) Received: from navgw.tt.kgt.co.jp (navgw [210.141.246.71]) by titan.kgt.co.jp (Postfix) with ESMTP id C56554A24A for ; Fri, 16 May 2003 12:44:19 +0900 (JST) Received: from tt.kgt.co.jp (pegasus [192.168.10.1]) by navgw.tt.kgt.co.jp (Postfix) with ESMTP id A2F8847711 for ; Fri, 16 May 2003 12:44:19 +0900 (JST) Received: from localhost [192.168.13.83] by tt.kgt.co.jp with ESMTP (SMTPD32-7.12) id AE938F009E; Fri, 16 May 2003 12:44:19 +0900 Date: Fri, 16 May 2003 12:44:18 +0900 (JST) Message-Id: <20030516.124418.74754576.haro@kgt.co.jp> To: freebsd-threads@freebsd.org From: Munehiro Matsuda X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: libthr dies with 'Illegal call from signal handler' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 03:44:22 -0000 Hi all, I'm trying out the latest libthr.so and occasionally get following error which kills application. Fatal error 'Illegal call from signal handler' at line 1352 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0) Now, what can I do to help debug this problem? BTW, I'm testing with -libthr.so: sources from 2003/05/15 17:00:00 PDT -kernel: 5.1-BETA from Thu May 15 09:00:00 JST 2003 -user-land: Thu May 15 09:00:00 JST 2003 -applicaton: mozilla1.3 + jdk1.3.1p8 (with HotSpot + local patch for libthr) + some web-pages with Applets Thanks, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Network & Security Dept., Kubota Graphics Technologies Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0373 Fax: +81-3-3225-0740 Email: haro@kgt.co.jp From owner-freebsd-threads@FreeBSD.ORG Fri May 16 06:37:13 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EF4837B401 for ; Fri, 16 May 2003 06:37:13 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5195B43FCB for ; Fri, 16 May 2003 06:37:12 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.4.52]) by out005.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030516133711.DPA25152.out005.verizon.net@kokeb.ambesa.net>; Fri, 16 May 2003 08:37:11 -0500 Date: Fri, 16 May 2003 09:37:07 -0400 From: Mike Makonnen To: Munehiro Matsuda In-Reply-To: <20030516.124418.74754576.haro@kgt.co.jp> References: <20030516.124418.74754576.haro@kgt.co.jp> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [138.88.4.52] at Fri, 16 May 2003 08:37:07 -0500 Message-Id: <20030516133711.DPA25152.out005.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org Subject: Re: libthr dies with 'Illegal call from signal handler' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 13:37:13 -0000 On Fri, 16 May 2003 12:44:18 +0900 (JST) Munehiro Matsuda wrote: > Hi all, > > I'm trying out the latest libthr.so and occasionally get following error > which kills application. > > Fatal error 'Illegal call from signal handler' at line 1352 in file > /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0) This normally happens when a thread goes to queue on a mutex or cv (in your case it's a mutex) and finds out it's already on one of the queue's. Normally, a thread is suspended while on a queue, so the reasoning is that if it's hitting this assertion it must be in a signal handler, but since libthr is not fully locked yet this may not be the case. > > Now, what can I do to help debug this problem? > Well, it would be very helpful if you could recompile the application, libthr, and libc with debuging symbols and post a backtrace. Also, the following patch will print more information on the thread and which queue it's on. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve Index: lib/libthr/thread/thr_mutex.c =================================================================== RCS file: /home/ncvs/src/lib/libthr/thread/thr_mutex.c,v retrieving revision 1.6 diff -u -r1.6 thr_mutex.c --- lib/libthr/thread/thr_mutex.c 12 May 2003 10:48:02 -0000 1.6 +++ lib/libthr/thread/thr_mutex.c 16 May 2003 13:24:53 -0000 @@ -1347,8 +1347,16 @@ static inline void mutex_queue_enq(pthread_mutex_t mutex, pthread_t pthread) { + char *name; pthread_t tid = TAILQ_LAST(&mutex->m_queue, mutex_head); + name = pthread->name ? pthread->name : "(null)"; + if ((pthread->flags & PTHREAD_FLAGS_IN_CONDQ) != 0) + _thread_printf(2, "Thread (%s:%u) already on condq\n", + pthread->name, pthread->uniqueid); + if ((pthread->flags & PTHREAD_FLAGS_IN_MUTEXQ) != 0) + _thread_printf(2, "Thread (%s:%u) already on mutexq\n", + pthread->name, pthread->uniqueid); PTHREAD_ASSERT_NOT_IN_SYNCQ(pthread); /* * For the common case of all threads having equal priority,