From owner-freebsd-threads@FreeBSD.ORG Mon Dec 11 11:15:36 2006 Return-Path: X-Original-To: freebsd-threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B692A16A5FC for ; Mon, 11 Dec 2006 11:15:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD5A943D60 for ; Mon, 11 Dec 2006 11:07:45 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kBBB91YX023029 for ; Mon, 11 Dec 2006 11:09:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kBBB8xI5023025 for freebsd-threads@FreeBSD.org; Mon, 11 Dec 2006 11:08:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Dec 2006 11:08:59 GMT Message-Id: <200612111108.kBBB8xI5023025@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon 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, 11 Dec 2006 11:15:36 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72353 threads Assertion fails in /usr/src/lib/libpthread/sys/lock.c, o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o threa/90278 threads libthr, ULE and -current produces >100% WCPU with apac o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc f threa/98256 threads gnome-system-monitor core dumps from pthread_testcance s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash 29 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/74180 threads KSE problem. Applications those riched maximum possibl o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty 10 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 11 15:07:10 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBFE516A403; Mon, 11 Dec 2006 15:07:10 +0000 (UTC) (envelope-from arnej@pvv.ntnu.no) Received: from decibel.pvv.ntnu.no (decibel.pvv.ntnu.no [129.241.210.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 382E243CAC; Mon, 11 Dec 2006 15:05:53 +0000 (GMT) (envelope-from arnej@pvv.ntnu.no) Received: from arnej by decibel.pvv.ntnu.no with local (Exim 4.60) (envelope-from ) id 1GtmkH-00080J-6z; Mon, 11 Dec 2006 16:07:09 +0100 Date: Mon, 11 Dec 2006 16:07:09 +0100 (CET) From: "Arne H. Juul" To: freebsd-java@FreeBSD.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 11 Dec 2006 15:07:11 -0000 On Mon, 11 Dec 2006, Arne H. Juul wrote: > I've had problems with some tests hanging on FreeBSD 6/amd64. This happens > both with diablo-1.5.0_07-b01 and the java/jdk15 compiled from ports. > > After much digging we've determined that the root cause is that > the guarantee in the socket.close() API, see the documentation at > http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#close() > isn't fulfulled - the thread blocked in I/O on the socket doesn't wake up. Looking at the Java VM source code it does some tricks with dup2() to reopen the close()'d filedescriptor, making it point to a filedescriptor that's pre-connected to a closed socket. A small C program that duplicates this (using pipes to make it a bit simpler) follows. I'm not sure if any standards demand that this works like it used to on FreeBSD 4 / libc_r, but since Java uses it it would be really nice if this could be made to work in FreeBSD 6 (libthr and libpthread). Or maybe somebody has another suggestions on how to implement the Java close() semantics? Anyway, the following C program works as intended on FreeBSD 4, hangs on FreeBSD 6 (amd64), compiled with: cc -Wall -pthread read_dup2.c -o read_dup2 #include #include #include #include #include int p[2]; void *run(void *arg) { ssize_t res; char tmp[128]; fprintf(stderr, "reading...\n"); res = read(p[0], tmp, sizeof(tmp)); fprintf(stderr, "read result: %d\n", (int)res); if (res < 0) { perror("read"); } return arg; } int main(int argc, char **argv) { pthread_t t; int d = open("/dev/null", O_RDONLY); if (pipe(p) != 0) { perror("pipe"); return 1; } if (pthread_create(&t, NULL, run, NULL) != 0) { perror("thread create"); return 1; } sleep(1); d = open("/dev/null", O_RDONLY); if (d < 0) { perror("open dev null"); exit(1); } if (dup2(d, p[0]) < 0) { perror("dup2"); exit(1); } if (pthread_join(t, NULL) != 0) { perror("thread join"); exit(1); } return 0; } From owner-freebsd-threads@FreeBSD.ORG Wed Dec 13 23:04:54 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0582D16A403 for ; Wed, 13 Dec 2006 23:04:54 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E3E43CA4 for ; Wed, 13 Dec 2006 23:03:21 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp8-g19.free.fr (Postfix) with ESMTP id 5AA9F55D5; Thu, 14 Dec 2006 00:04:52 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id E56DA9B46E; Wed, 13 Dec 2006 23:05:51 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id B72CD405B; Thu, 14 Dec 2006 00:05:51 +0100 (CET) Date: Thu, 14 Dec 2006 00:05:51 +0100 From: Jeremie Le Hen To: Joshua M Message-ID: <20061213230551.GA94832@obiwan.tataz.chchile.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-threads@freebsd.org Subject: Re: Threading arch quetions 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: Wed, 13 Dec 2006 23:04:54 -0000 On Mon, Dec 04, 2006 at 09:02:57PM +0100, Joshua M wrote: > Sorry for disturbing but i have some questions concerning threaded arch in > FreeBSD. > Sorry for possible repeating also. > > 1. What was primary concern when adopting KSE based threading model ? > 2. Is there benchmarks comparing Linux's NPTL and KSE based pthreads in > FreeBSD ? I've bookmarked a few detailed posts about this topic. You may want have a look to them: http://lists.freebsd.org/pipermail/freebsd-threads/2006-July/003609.html http://lists.freebsd.org/pipermail/freebsd-current/2006-October/066786.html Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-threads@FreeBSD.ORG Fri Dec 15 18:00:06 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8F7716A416 for ; Fri, 15 Dec 2006 18:00:06 +0000 (UTC) (envelope-from peadar.edwards@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB79243CC1 for ; Fri, 15 Dec 2006 17:58:22 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so454270wra for ; Fri, 15 Dec 2006 10:00:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=Z+M3OP8hX3iB1Hw0PzzIdUdeErnTCLntlnzIsB33LlIdZ1So45a/VULU92JrGul0hSm6Kc036/O48o6kqqqNdeOq5mvDmdZN583Pp6a0fP3rrUP+LoZG4uZwHwaUnEwDwB2fwwI2fAByxS3nmg8jA2PW4Jmo4GrwxVxwrPST464= Received: by 10.90.105.20 with SMTP id d20mr1088236agc.1166205604817; Fri, 15 Dec 2006 10:00:04 -0800 (PST) Received: by 10.90.89.13 with HTTP; Fri, 15 Dec 2006 10:00:04 -0800 (PST) Message-ID: <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com> Date: Fri, 15 Dec 2006 18:00:04 +0000 From: "Peter Edwards" Sender: peadar.edwards@gmail.com To: freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_115896_14548060.1166205604757" X-Google-Sender-Auth: cc95d030bb96a45a Subject: libpthread problem + possible solution 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: Fri, 15 Dec 2006 18:00:07 -0000 ------=_Part_115896_14548060.1166205604757 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've a problem when a process uses: libpthread detached threads mixed bound/unbound threads suspended threads (a la pthread_resume_np()) whereby some newly created suspended threads don't get scheduled. I think I've tracked it down, so if someone could review the reasoning, I'd be grateful. Newly launched threads have a "struct pthread" that may be allocated from a freelist of GCed threads. Apparently, when detached threads enter the GCed list, they can still have the "active" flag set on them. Later, this causes problems when this thread is recycled and resumed, because _thr_setrunnable_unlocked() doesn't add it to a run queue. thr_cleanup can be called either from the bound-threads scheduler, or the unbound scheduler. One callsite clears "active", "needswitchout", and "lock_switch" to zero before the call. The other callsite just clears "check_pending". I think these flags are all either bound-thread or unbound-thread specific, and that there was an unintended assumption that the thread would remain with the same "boundedness" after being recycled, which isn't neccessarily the case. (Or another way - the idea was that there was no need to clear the "active" flag on a bound thread, as its only used for unbound threads, but a GCed bound thread might be recycled into an unbound thread) Given that, it seems correct to clean up the thread the same way for both cases, and just move that code into thr_cleanup. So, does the attached patch make sense? I can commit it if someone gives me the nod. (It definitely fixes my specific problem with threads not getting scheduled.) ------=_Part_115896_14548060.1166205604757 Content-Type: text/plain; name=pthread.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_evqwn9nn Content-Disposition: attachment; filename="pthread.txt" SW5kZXg6IGxpYi9saWJwdGhyZWFkL3RocmVhZC90aHJfa2Vybi5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZp bGU6IC9uZXQvZHlzb24vZXhwb3J0L2hvbWUvcGV0ZXJlL0ZyZWVCU0QtQ1ZTL3NyYy9saWIvbGli cHRocmVhZC90aHJlYWQvdGhyX2tlcm4uYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMTYuMi4x CmRpZmYgLXUgLXIxLjExNi4yLjEgdGhyX2tlcm4uYwotLS0gbGliL2xpYnB0aHJlYWQvdGhyZWFk L3Rocl9rZXJuLmMJMTYgTWFyIDIwMDYgMjM6Mjk6MDcgLTAwMDAJMS4xMTYuMi4xCisrKyBsaWIv bGlicHRocmVhZC90aHJlYWQvdGhyX2tlcm4uYwkxNSBEZWMgMjAwNiAxNzo0ODoyMCAtMDAwMApA QCAtNzY0LDcgKzc2NCw2IEBACiAJCWJyZWFrOwogCiAJY2FzZSBQU19ERUFEOgotCQljdXJ0aHJl YWQtPmNoZWNrX3BlbmRpbmcgPSAwOwogCQkvKiBVbmxvY2sgdGhlIHNjaGVkdWxpbmcgcXVldWUg YW5kIGV4aXQgdGhlIEtTRSBhbmQgdGhyZWFkLiAqLwogCQl0aHJfY2xlYW51cChjdXJrc2UsIGN1 cnRocmVhZCk7CiAJCUtTRV9TQ0hFRF9VTkxPQ0soY3Vya3NlLCBjdXJrc2UtPmtfa3NlZyk7CkBA IC0xMTUwLDYgKzExNDksMTEgQEAKIAlzdHJ1Y3Qga3NlX21haWxib3ggKmttYnggPSBOVUxMOwog CWludCBzeXNfc2NvcGU7CiAKKwl0aHJlYWQtPmFjdGl2ZSA9IDA7CisJdGhyZWFkLT5uZWVkX3N3 aXRjaG91dCA9IDA7CisJdGhyZWFkLT5sb2NrX3N3aXRjaCA9IDA7CisJdGhyZWFkLT5jaGVja19w ZW5kaW5nID0gMDsKKwogCWlmICgoam9pbmVyID0gdGhyZWFkLT5qb2luZXIpICE9IE5VTEwpIHsK IAkJLyogSm9pbmVlIHNjaGVkdWxlciBsb2NrIGhlbGQ7IGpvaW5lciB3b24ndCBsZWF2ZS4gKi8K IAkJaWYgKGpvaW5lci0+a3NlZyA9PSBjdXJrc2UtPmtfa3NlZykgewpAQCAtMTcxNyw5ICsxNzIx LDYgQEAKIAkJCSAqIHN0YWNrLiAgSXQgaXMgc2FmZSB0byBkbyBnYXJiYWdlIGNvbGxlY3RpbmcK IAkJCSAqIGhlcmUuCiAJCQkgKi8KLQkJCXRocmVhZC0+YWN0aXZlID0gMDsKLQkJCXRocmVhZC0+ bmVlZF9zd2l0Y2hvdXQgPSAwOwotCQkJdGhyZWFkLT5sb2NrX3N3aXRjaCA9IDA7CiAJCQl0aHJf Y2xlYW51cChrc2UsIHRocmVhZCk7CiAJCQlyZXR1cm47CiAJCQlicmVhazsK ------=_Part_115896_14548060.1166205604757-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 15 20:11:50 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AFE216A40F; Fri, 15 Dec 2006 20:11:50 +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 B95C843CA1; Fri, 15 Dec 2006 20:10:06 +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.8/8.13.8/NETPLEX) with ESMTP id kBFKBmfO020796; Fri, 15 Dec 2006 15:11:48 -0500 (EST) Date: Fri, 15 Dec 2006 15:11:48 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Peter Edwards In-Reply-To: <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com> Message-ID: References: <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-ID: Content-Disposition: inline X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Fri, 15 Dec 2006 15:11:48 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: libpthread problem + possible solution 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: Fri, 15 Dec 2006 20:11:50 -0000 On Fri, 15 Dec 2006, Peter Edwards wrote: > Hi, > > I've a problem when a process uses: > libpthread > detached threads > mixed bound/unbound threads > suspended threads (a la pthread_resume_np()) > > whereby some newly created suspended threads don't get scheduled. > I think I've tracked it down, so if someone could review the > reasoning, I'd be grateful. I'm away for a few days, so I'd appreciate you waiting until early next week -- unless David Xu looks at it and gives it the ok. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Dec 15 20:14:48 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83B6116A5C2 for ; Fri, 15 Dec 2006 20:14:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90E7D43CBA for ; Fri, 15 Dec 2006 20:12:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 15 Dec 2006 11:59:11 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBFKBhUL081251; Fri, 15 Dec 2006 12:11:44 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <45830177.304@elischer.org> Date: Fri, 15 Dec 2006 12:11:35 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Peter Edwards References: <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com> In-Reply-To: <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: libpthread problem + possible solution 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: Fri, 15 Dec 2006 20:14:48 -0000 Peter Edwards wrote: > Hi, > > I've a problem when a process uses: > libpthread > detached threads > mixed bound/unbound threads > suspended threads (a la pthread_resume_np()) > > whereby some newly created suspended threads don't get scheduled. > I think I've tracked it down, so if someone could review the > reasoning, I'd be grateful. > > Newly launched threads have a "struct pthread" that may be allocated > from a freelist of GCed threads. Apparently, when detached threads > enter the GCed list, they can still have the "active" flag set on > them. Later, this causes problems when this thread is recycled and > resumed, because _thr_setrunnable_unlocked() doesn't add it to a > run queue. > > thr_cleanup can be called either from the bound-threads scheduler, > or the unbound scheduler. One callsite clears "active", "needswitchout", > and "lock_switch" to zero before the call. The other callsite just > clears "check_pending". I think these flags are all either bound-thread > or unbound-thread specific, and that there was an unintended > assumption that the thread would remain with the same "boundedness" > after being recycled, which isn't neccessarily the case. (Or another > way - the idea was that there was no need to clear the "active" > flag on a bound thread, as its only used for unbound threads, but > a GCed bound thread might be recycled into an unbound thread) > > Given that, it seems correct to clean up the thread the same way > for both cases, and just move that code into thr_cleanup. So, does > the attached patch make sense? I can commit it if someone gives me > the nod. (It definitely fixes my specific problem with threads not > getting scheduled.) your logic sounds sound.. I'll wait for DAN to make a pronouncement however. > > > ------------------------------------------------------------------------ > > Index: lib/libpthread/thread/thr_kern.c > =================================================================== > RCS file: /net/dyson/export/home/petere/FreeBSD-CVS/src/lib/libpthread/thread/thr_kern.c,v > retrieving revision 1.116.2.1 > diff -u -r1.116.2.1 thr_kern.c > --- lib/libpthread/thread/thr_kern.c 16 Mar 2006 23:29:07 -0000 1.116.2.1 > +++ lib/libpthread/thread/thr_kern.c 15 Dec 2006 17:48:20 -0000 > @@ -764,7 +764,6 @@ > break; > > case PS_DEAD: > - curthread->check_pending = 0; > /* Unlock the scheduling queue and exit the KSE and thread. */ > thr_cleanup(curkse, curthread); > KSE_SCHED_UNLOCK(curkse, curkse->k_kseg); > @@ -1150,6 +1149,11 @@ > struct kse_mailbox *kmbx = NULL; > int sys_scope; > > + thread->active = 0; > + thread->need_switchout = 0; > + thread->lock_switch = 0; > + thread->check_pending = 0; > + > if ((joiner = thread->joiner) != NULL) { > /* Joinee scheduler lock held; joiner won't leave. */ > if (joiner->kseg == curkse->k_kseg) { > @@ -1717,9 +1721,6 @@ > * stack. It is safe to do garbage collecting > * here. > */ > - thread->active = 0; > - thread->need_switchout = 0; > - thread->lock_switch = 0; > thr_cleanup(kse, thread); > return; > break; > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" From owner-freebsd-threads@FreeBSD.ORG Sat Dec 16 01:00:59 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 74A7816A415; Sat, 16 Dec 2006 01:00:59 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-threads@freebsd.org, Daniel Eischen Date: Sat, 16 Dec 2006 09:00:54 +0800 User-Agent: KMail/1.8.2 References: <34cb7c840612151000s4a3e1f2dvd71a60d66cf7c4be@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612160900.54707.davidxu@freebsd.org> Cc: Peter Edwards Subject: Re: libpthread problem + possible solution 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: Sat, 16 Dec 2006 01:00:59 -0000 On Saturday 16 December 2006 04:11, Daniel Eischen wrote: > On Fri, 15 Dec 2006, Peter Edwards wrote: > > Hi, > > > > I've a problem when a process uses: > > libpthread > > detached threads > > mixed bound/unbound threads > > suspended threads (a la pthread_resume_np()) > > > > whereby some newly created suspended threads don't get scheduled. > > I think I've tracked it down, so if someone could review the > > reasoning, I'd be grateful. > > I'm away for a few days, so I'd appreciate you waiting until > early next week -- unless David Xu looks at it and gives it > the ok. I will review it. David Xu