From owner-freebsd-threads@FreeBSD.ORG Mon May 22 11:03:08 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 9180916A5AE for ; Mon, 22 May 2006 11:03:08 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0464043D79 for ; Mon, 22 May 2006 11:03:08 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k4MB37qp035045 for ; Mon, 22 May 2006 11:03:07 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k4MB36YI035041 for freebsd-threads@freebsd.org; Mon, 22 May 2006 11:03:06 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 22 May 2006 11:03:06 GMT Message-Id: <200605221103.k4MB36YI035041@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2006 11:03:13 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can s [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT s [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock s [2001/11/26] bin/32295 threads pthread dont dequeue signals s [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe s [2002/06/27] threads/39922threads [threads] [patch] Threaded applications e o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag s [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z s [2003/03/10] threads/49087threads Signals lost in programs linked with libc s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag s [2005/01/26] threads/76694threads fork cause hang in dup()/close() function o [2005/04/08] threads/79683threads svctcp_create() fails if multiple threads o [2005/04/28] threads/80435threads panic on high loads o [2005/05/19] threads/81258threads Thread specific data is sometimes assigne o [2005/07/22] threads/83914threads [libc] popen() doesn't work in static thr s [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x o [2005/08/20] threads/85160threads [libthr] [patch] libobjc + libpthread/lib p [2005/11/19] threads/89262threads [kernel] [patch] multi-threaded process h o [2005/12/12] threads/90278threads libthr, ULE and -current produces >100% W o [2006/01/03] kern/91266 threads [threads] Trying sleep, but thread marked s [2006/03/15] threads/94467threads send(), sendto() and sendmsg() are not co 29 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything s [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f s [2001/09/09] threads/30464threads pthread mutex attributes -- pshared s [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from s [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/04/13] threads/79887threads [patch] freopen() isn't thread-safe o [2005/05/13] threads/80992threads abort() sometimes not caught by gdb depen o [2005/05/26] threads/81534threads [libc_r] [patch] libc_r close() will fail 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed May 24 22:14:27 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 03C1216A581 for ; Wed, 24 May 2006 22:14:27 +0000 (UTC) (envelope-from lists@intricatesoftware.com) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ECF543D46 for ; Wed, 24 May 2006 22:14:25 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0IZS00JNTJ3OZRO0@mta1.srv.hcvlny.cv.net> for freebsd-threads@freebsd.org; Wed, 24 May 2006 18:14:12 -0400 (EDT) Date: Wed, 24 May 2006 18:14:11 -0400 From: Kurt Miller To: freebsd-threads@freebsd.org Message-id: <200605241814.11452.lists@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.9.1 Subject: pthread_cond_signal w/suspended threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 22:14:31 -0000 I've been working on an intermittent deadlock in the jvm and have isolated it to the following issue. When multiple threads are waiting on a condition variable and some of those threads have been suspended with pthread_suspend_np(), there is an expectation that pthread_cond_signal() will signal an unsuspended thread first. However, the following program shows this is not the case on 6.1-release/kse (thr works as expected). Can kse behavior be changed to signal unsuspended threads first? #include #include #include #include pthread_cond_t cond = PTHREAD_COND_INITIALIZER; pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; static void * start_routine(void *arg) { pthread_mutex_lock(&mutex); pthread_cond_wait(&cond, &mutex); printf("unblocked %d\n", (int)arg); pthread_mutex_unlock(&mutex); return (0); } int main(int argc, char *argv[]) { pthread_t thread1; pthread_t thread2; pthread_create(&thread1, NULL, start_routine, (void *)1); sleep(1); pthread_create(&thread2, NULL, start_routine, (void *)2); sleep(1); pthread_suspend_np(thread1); pthread_cond_signal(&cond); sleep(1); pthread_resume_np(thread1); sleep(1); return (0); } From owner-freebsd-threads@FreeBSD.ORG Wed May 24 23:07:32 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 E60A516A540 for ; Wed, 24 May 2006 23:07:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 446C443D58 for ; Wed, 24 May 2006 23:07:32 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k4ON7U2H003830; Wed, 24 May 2006 19:07:30 -0400 (EDT) Date: Wed, 24 May 2006 19:07:30 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: kurt@intricatesoftware.com In-Reply-To: <200605241814.11452.lists@intricatesoftware.com> Message-ID: References: <200605241814.11452.lists@intricatesoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: pthread_cond_signal w/suspended threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 23:07:34 -0000 On Wed, 24 May 2006, Kurt Miller wrote: > I've been working on an intermittent deadlock in > the jvm and have isolated it to the following issue. > When multiple threads are waiting on a condition > variable and some of those threads have been suspended > with pthread_suspend_np(), there is an expectation that > pthread_cond_signal() will signal an unsuspended thread > first. However, the following program shows this is not > the case on 6.1-release/kse (thr works as expected). > > Can kse behavior be changed to signal unsuspended > threads first? Relying on this behavior isn't exactly portable, and what if there are no unsuspended threads when the signal occurs. A suspended thread would still be signaled in that case. The whole suspended threads thing is kind of dangerous anyways. If one of these threads hold a lock, or is waiting in some other queue, then deadlock can occur. I think you need a way of waiting until they are out of critical regions before you suspend them in order for this not to cause problems. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu May 25 14:50:12 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 5A5A916A4E3; Thu, 25 May 2006 14:50:12 +0000 (UTC) (envelope-from kurt@intricatesoftware.com) Received: from mta3.srv.hcvlny.cv.net (mta3.srv.hcvlny.cv.net [167.206.4.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0556243D4C; Thu, 25 May 2006 14:50:09 +0000 (GMT) (envelope-from kurt@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0IZT00FF9T6N13C0@mta3.srv.hcvlny.cv.net>; Thu, 25 May 2006 10:49:35 -0400 (EDT) Date: Thu, 25 May 2006 10:49:33 -0400 From: Kurt Miller In-reply-to: To: freebsd-threads@freebsd.org, Daniel Eischen Message-id: <200605251049.34486.kurt@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: <200605241814.11452.lists@intricatesoftware.com> User-Agent: KMail/1.9.1 Cc: Subject: Re: pthread_cond_signal w/suspended threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 14:50:13 -0000 On Wednesday 24 May 2006 7:07 pm, Daniel Eischen wrote: > On Wed, 24 May 2006, Kurt Miller wrote: > > > I've been working on an intermittent deadlock in > > the jvm and have isolated it to the following issue. > > When multiple threads are waiting on a condition > > variable and some of those threads have been suspended > > with pthread_suspend_np(), there is an expectation that > > pthread_cond_signal() will signal an unsuspended thread > > first. However, the following program shows this is not > > the case on 6.1-release/kse (thr works as expected). > > > > Can kse behavior be changed to signal unsuspended > > threads first? > > Relying on this behavior isn't exactly portable, and what > if there are no unsuspended threads when the signal occurs. > A suspended thread would still be signaled in that case. I agree its not portable, but we are talking about a non portable function (pthread_suspend_np). :-) Since we have some latitude here, doesn't it make sense to have our pthread_suspend_np be feature compatible with Solaris? At least in the case of the jvm it would help a bit if this behavior matched Solaris. Below is a diff that makes the behavior change for your consideration. Also the test program converted for Solaris is after that. As it turns out there are two deadlocks I've found. The one described here appears to be hard to reproduce and occurs upon jvm shutdown. In fact I haven't been able to reproduce it again. The other deadlock I'll post under another thread when I make a C program to reproduce it and if it appears to be a thread issue. > The whole suspended threads thing is kind of dangerous > anyways. If one of these threads hold a lock, or is > waiting in some other queue, then deadlock can occur. > I think you need a way of waiting until they are out > of critical regions before you suspend them in order > for this not to cause problems. Sure, I agree. Right now the only alternative I see is to not use pthread_suspend/resume_np and do thread suspension with signals the way hotspot does it for linux. I'd perfer not to do that if possible. --- thr_cond.c.orig Wed May 24 21:36:18 2006 +++ thr_cond.c Thu May 25 10:44:46 2006 @@ -596,13 +596,23 @@ (*cond)->c_seqno++; /* + * Wakeup the first unsuspended thread, otherwise + * the first suspended. Matches Solaris behavior. + */ + pthread = TAILQ_FIRST(&(*cond)->c_queue); + while (pthread != NULL && + (pthread->flags & THR_FLAGS_SUSPENDED) != 0) + pthread = TAILQ_NEXT(pthread, sqe); + if (pthread == NULL) + pthread = TAILQ_FIRST(&(*cond)->c_queue); + + /* * Wakeups have to be done with the CV lock held; * otherwise there is a race condition where the * thread can timeout, run on another KSE, and enter * another blocking state (including blocking on a CV). */ - if ((pthread = TAILQ_FIRST(&(*cond)->c_queue)) - != NULL) { + if (pthread != NULL) { THR_SCHED_LOCK(curthread, pthread); cond_queue_remove(*cond, pthread); pthread->sigbackout = NULL; #include #include #include #include cond_t cond; mutex_t mutex; static void * start_routine(void *arg) { mutex_lock(&mutex); cond_wait(&cond, &mutex); printf("unblocked %d\n", (int)arg); mutex_unlock(&mutex); return (0); } int main(int argc, char *argv[]) { thread_t thread1; thread_t thread2; cond_init(&cond, NULL, NULL); mutex_init(&mutex, NULL, NULL); thr_create(NULL, NULL, start_routine, (void *)1, NULL, &thread1); sleep(1); thr_create(NULL, NULL, start_routine, (void *)2, NULL, &thread2); sleep(1); thr_suspend(thread1); cond_signal(&cond); sleep(1); thr_continue(thread1); sleep(1); return (0); } From owner-freebsd-threads@FreeBSD.ORG Thu May 25 15:58:39 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 1D04516A434 for ; Thu, 25 May 2006 15:58:39 +0000 (UTC) (envelope-from lists@intricatesoftware.com) Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.4.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id C668443D46 for ; Thu, 25 May 2006 15:58:38 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta6.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0IZT002STWDNHXZ0@mta6.srv.hcvlny.cv.net> for freebsd-threads@freebsd.org; Thu, 25 May 2006 11:58:36 -0400 (EDT) Date: Thu, 25 May 2006 11:58:34 -0400 From: Kurt Miller To: freebsd-threads@freebsd.org Message-id: <200605251158.34553.lists@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.9.1 Subject: close() socket deadlocks blocked threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 15:58:44 -0000 Here's the other deadlock I mentioned. When a thread is blocked waiting for data on a socket and another thread closes the socket, the blocked thread remains blocked indefinitely. Both kse and thr have this issue. c_r returns with -1 errno==EBADF. Solaris returns with -1 errno==0. #include #include #include #include #include #include #include #include #include #include #include static void * start_routine(void *arg) { int sock1 = (int)arg; struct sockaddr remote_addr; char readBuf; int n, remote_addr_len = sizeof(struct sockaddr); n = recvfrom(sock1, &readBuf, 1, 0, &remote_addr, &remote_addr_len); if (n == -1) { printf("unblocked with errno = %d\n", errno); } return (0); } void buildAddr4(struct sockaddr_in *addr4, int address, short port) { memset((char *) addr4, 0, sizeof(struct sockaddr_in)); addr4->sin_port = htons(port); addr4->sin_addr.s_addr = (uint32_t) htonl(address); addr4->sin_family = AF_INET; } int main() { int sock1; struct sockaddr addr; pthread_t thread1; void *value_ptr; buildAddr4((struct sockaddr_in *)&addr, 0, 0); if ((sock1 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) exit(1); if (bind(sock1, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) != 0) exit(1); pthread_create(&thread1, NULL, start_routine, (void *)sock1); sleep(1); close(sock1); pthread_join(thread1, &value_ptr); return (0); } From owner-freebsd-threads@FreeBSD.ORG Thu May 25 17:09:20 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 8B44916A6D4 for ; Thu, 25 May 2006 17:09:20 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C314443D46 for ; Thu, 25 May 2006 17:09:19 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k4PH9IAk023316; Thu, 25 May 2006 13:09:18 -0400 (EDT) Date: Thu, 25 May 2006 13:09:18 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: kurt@intricatesoftware.com In-Reply-To: <200605251158.34553.lists@intricatesoftware.com> Message-ID: References: <200605251158.34553.lists@intricatesoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: close() socket deadlocks blocked threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 17:09:22 -0000 On Thu, 25 May 2006, Kurt Miller wrote: > Here's the other deadlock I mentioned. When a thread > is blocked waiting for data on a socket and another > thread closes the socket, the blocked thread remains > blocked indefinitely. Both kse and thr have this > issue. c_r returns with -1 errno==EBADF. Solaris > returns with -1 errno==0. You should send this to -current, or -stable if it works correctly on -current. There isn't anything we can do in the threads libraries about this. I'm not sure what the correct behavior should be. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu May 25 17:48:00 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 6285E16B1EE; Thu, 25 May 2006 17:48:00 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 141E643D4C; Thu, 25 May 2006 17:47:55 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id D3B225E492F; Thu, 25 May 2006 10:47:54 -0700 (PDT) Received: from [192.168.168.201] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 488315E4903; Thu, 25 May 2006 10:47:53 -0700 (PDT) Message-ID: <4475EDC6.10508@FreeBSD.org> Date: Thu, 25 May 2006 10:47:50 -0700 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.8-1.4.1 (X11/20060420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kurt Miller References: <200605241814.11452.lists@intricatesoftware.com> <200605251049.34486.kurt@intricatesoftware.com> In-Reply-To: <200605251049.34486.kurt@intricatesoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.5 Cc: Daniel Eischen , freebsd-threads@freebsd.org Subject: Re: pthread_cond_signal w/suspended threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 17:48:07 -0000 Kurt Miller wrote: > On Wednesday 24 May 2006 7:07 pm, Daniel Eischen wrote: >>The whole suspended threads thing is kind of dangerous >>anyways. If one of these threads hold a lock, or is >>waiting in some other queue, then deadlock can occur. >>I think you need a way of waiting until they are out >>of critical regions before you suspend them in order >>for this not to cause problems. > > Sure, I agree. Right now the only alternative I see is > to not use pthread_suspend/resume_np and do thread > suspension with signals the way hotspot does it for > linux. I'd perfer not to do that if possible. If the code requires protection from suspension via critical sections, it turns out that there's a nearly free lazy approach if you use signal-based suspend/resume that is way cheaper than preventative locking. So, although the suspend/resume APIs are seductive, there are many situations in which they are actually a pessimization. Jason From owner-freebsd-threads@FreeBSD.ORG Thu May 25 18:13:44 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 1E65216B41B; Thu, 25 May 2006 18:13:44 +0000 (UTC) (envelope-from kurt@intricatesoftware.com) Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.4.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6BD743D76; Thu, 25 May 2006 18:13:40 +0000 (GMT) (envelope-from kurt@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta6.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0IZU0026K2KWPP11@mta6.srv.hcvlny.cv.net>; Thu, 25 May 2006 14:12:33 -0400 (EDT) Date: Thu, 25 May 2006 14:12:32 -0400 From: Kurt Miller In-reply-to: To: Daniel Eischen Message-id: <200605251412.32677.kurt@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: <200605251158.34553.lists@intricatesoftware.com> User-Agent: KMail/1.9.1 Cc: freebsd-threads@freebsd.org Subject: Re: close() socket deadlocks blocked threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 18:13:57 -0000 On Thursday 25 May 2006 1:09 pm, Daniel Eischen wrote: > On Thu, 25 May 2006, Kurt Miller wrote: > > > Here's the other deadlock I mentioned. When a thread > > is blocked waiting for data on a socket and another > > thread closes the socket, the blocked thread remains > > blocked indefinitely. Both kse and thr have this > > issue. c_r returns with -1 errno==EBADF. Solaris > > returns with -1 errno==0. > > You should send this to -current, or -stable if it works > correctly on -current. There isn't anything we can do > in the threads libraries about this. I'm not sure what > the correct behavior should be. > Ok, thanks. I filed a kern PR instead since I don't have a -current or -stable box around to confirm. http://www.freebsd.org/cgi/query-pr.cgi?pr=97921 -Kurt