From owner-freebsd-threads@FreeBSD.ORG Mon Dec 17 06:55:08 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AE0516A421; Mon, 17 Dec 2007 06:55:08 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9F913C46A; Mon, 17 Dec 2007 06:55:08 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBH6t7rj010366; Mon, 17 Dec 2007 06:55:07 GMT (envelope-from davidxu@freefall.freebsd.org) Received: (from davidxu@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBH6t7NZ010362; Mon, 17 Dec 2007 06:55:07 GMT (envelope-from davidxu) Date: Mon, 17 Dec 2007 06:55:07 GMT Message-Id: <200712170655.lBH6t7NZ010362@freefall.freebsd.org> To: mark@verniernetworks.com, davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org From: davidxu@FreeBSD.org Cc: Subject: Re: threads/72429: threads blocked in stdio (fgets, etc) are not cancellable in 5.3 (works in 4.x) 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, 17 Dec 2007 06:55:08 -0000 Synopsis: threads blocked in stdio (fgets, etc) are not cancellable in 5.3 (works in 4.x) State-Changed-From-To: open->closed State-Changed-By: davidxu State-Changed-When: Mon Dec 17 06:54:26 UTC 2007 State-Changed-Why: stdio functions are not cancellation points. http://www.freebsd.org/cgi/query-pr.cgi?pr=72429 From owner-freebsd-threads@FreeBSD.ORG Mon Dec 17 11:07:08 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FB5316A4F0 for ; Mon, 17 Dec 2007 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E3F5413C45A for ; Mon, 17 Dec 2007 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBHB774H088386 for ; Mon, 17 Dec 2007 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBHB77ml088382 for freebsd-threads@FreeBSD.org; Mon, 17 Dec 2007 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Dec 2007 11:07:07 GMT Message-Id: <200712171107.lBHB77ml088382@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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, 17 Dec 2007 11:07:08 -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 -------------------------------------------------------------------------------- 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 f 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 o threa/70975 threads unexpected and unreliable behaviour when using SYSV se 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 s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc 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 o threa/110636 threads gdb(1): using gdb with multi thread application with l o threa/118715 threads kse problem 23 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- 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/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP 9 problems total. From owner-freebsd-threads@FreeBSD.ORG Thu Dec 20 23:10:02 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1549D16A469 for ; Thu, 20 Dec 2007 23:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB8CC13C508 for ; Thu, 20 Dec 2007 23:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBKNA17v075163 for ; Thu, 20 Dec 2007 23:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBKNA1RC075162; Thu, 20 Dec 2007 23:10:01 GMT (envelope-from gnats) Resent-Date: Thu, 20 Dec 2007 23:10:01 GMT Resent-Message-Id: <200712202310.lBKNA1RC075162@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Kuteynikov Dmitriy Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 834EE16A418 for ; Thu, 20 Dec 2007 23:00:36 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 7597613C45A for ; Thu, 20 Dec 2007 23:00:36 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id lBKN0DXk013451 for ; Thu, 20 Dec 2007 23:00:13 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id lBKN0D4S013450; Thu, 20 Dec 2007 23:00:13 GMT (envelope-from nobody) Message-Id: <200712202300.lBKN0D4S013450@www.freebsd.org> Date: Thu, 20 Dec 2007 23:00:13 GMT From: Kuteynikov Dmitriy To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/118910: Multithreading problem 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, 20 Dec 2007 23:10:02 -0000 >Number: 118910 >Category: threads >Synopsis: Multithreading problem >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 20 23:10:01 UTC 2007 >Closed-Date: >Last-Modified: >Originator: Kuteynikov Dmitriy >Release: 7.0-BETA2 >Organization: MEPHI >Environment: FreeBSD av113962 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Fri Nov 2 16:47:33 UTC 2007 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: I have average computer: Athlon XP 2000+ with 1024 Mb RAM. When I listen music (in Rhythmbox) and move a window of any application for 3 or more seconds music stops to play. I haven't noticed this problem in previous releases. Is it multithreading problem in kernel? >How-To-Repeat: pkg_add -r fluxbox pkg_add -r rhythmbox startx fluxbox rhythmbox Turn on music and move xterm window for some seconds. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 07:00:07 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D951A16A418 for ; Fri, 21 Dec 2007 07:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B60C213C4EB for ; Fri, 21 Dec 2007 07:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBL707vs002072 for ; Fri, 21 Dec 2007 07:00:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBL707MZ002071; Fri, 21 Dec 2007 07:00:07 GMT (envelope-from gnats) Date: Fri, 21 Dec 2007 07:00:07 GMT Message-Id: <200712210700.lBL707MZ002071@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: David Xu Cc: Subject: Re: threads/118910: Multithreading problem X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2007 07:00:07 -0000 The following reply was made to PR threads/118910; it has been noted by GNATS. From: David Xu To: Kuteynikov Dmitriy Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/118910: Multithreading problem Date: Fri, 21 Dec 2007 14:56:35 +0800 Kuteynikov Dmitriy wrote: >> Number: 118910 >> Category: threads >> Synopsis: Multithreading problem >> Confidential: no >> Severity: serious >> Priority: high >> Responsible: freebsd-threads >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Thu Dec 20 23:10:01 UTC 2007 >> Closed-Date: >> Last-Modified: >> Originator: Kuteynikov Dmitriy >> Release: 7.0-BETA2 >> Organization: > MEPHI >> Environment: > FreeBSD av113962 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Fri Nov 2 16:47:33 UTC 2007 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> Description: > I have average computer: Athlon XP 2000+ with 1024 Mb RAM. When I listen music (in Rhythmbox) and move a window of any application for 3 or more seconds music stops to play. I haven't noticed this problem in previous releases. Is it multithreading problem in kernel? >> How-To-Repeat: > pkg_add -r fluxbox > pkg_add -r rhythmbox > startx > fluxbox > rhythmbox > Turn on music and move xterm window for some seconds. >> Fix: > > >> Release-Note: >> Audit-Trail: >> Unformatted: The kernel condition variable implementation is problematic, a thread sleeping on a condition variable does not raise its priority to some I/O priority, but most code will raise thread's priority to some level with msleep(). The code in sound driver use lots of cv_broadcast call(), it does not raise thread priority, this causes the music player does not have more chances to do I/O while other I/O bound applications will have. The kernel condition variable also causes top() to display incorrect priority because cv_wait does not update the priority but it is updated by cv_broadcastpri() which is too late for top to display. The kernel condition variable's initialization function should accept a thread priority parameter, and all thread sleep on the condition variable should use the priority. Regards, David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 07:36:25 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C468116A418; Fri, 21 Dec 2007 07:36:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF2113C45A; Fri, 21 Dec 2007 07:36:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lBL7aOsp010016; Fri, 21 Dec 2007 02:36:24 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 21 Dec 2007 02:36:24 -0500 (EST) Date: Fri, 21 Dec 2007 02:36:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200712210700.lBL707MZ002071@freefall.freebsd.org> Message-ID: References: <200712210700.lBL707MZ002071@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 07:36:25 -0000 On Fri, 21 Dec 2007, David Xu wrote: > The kernel condition variable implementation is problematic, a > thread sleeping on a condition variable does not raise its priority > to some I/O priority, but most code will raise thread's priority to some > level with msleep(). The code in sound driver use lots of cv_broadcast > call(), it does not raise thread priority, this causes the music player > does not have more chances to do I/O while other I/O bound applications > will have. > > The kernel condition variable also causes top() to display incorrect > priority because cv_wait does not update the priority but it is updated > by cv_broadcastpri() which is too late for top to display. > > The kernel condition variable's initialization function should accept > a thread priority parameter, and all thread sleep on the condition > variable should use the priority. While your hypothesis of what is happening may be correct, I don't think the solution is quite right. msleep() has to go away, at least the priority parameter does. The kernel should be scheduling based on thread priorities that are not artificially elevated by parameters to msleep. The kernel CV and mutexes initialization functions should accept something like Solaris interrupt cookies (see mutex_init() and cv_init() in Solaris). All mutexes/CVs used by interrupt code should initialize their CVs and mutexes with something like this. I don't think they should be using a priority directly. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 07:40:40 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B314716A418; Fri, 21 Dec 2007 07:40:40 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A705913C468; Fri, 21 Dec 2007 07:40:40 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBL7ebPk033189; Fri, 21 Dec 2007 07:40:38 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476B6E35.508@freebsd.org> Date: Fri, 21 Dec 2007 15:41:41 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Daniel Eischen References: <200712210700.lBL707MZ002071@freefall.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 07:40:40 -0000 Daniel Eischen wrote: > On Fri, 21 Dec 2007, David Xu wrote: > >> The kernel condition variable implementation is problematic, a >> thread sleeping on a condition variable does not raise its priority >> to some I/O priority, but most code will raise thread's priority to some >> level with msleep(). The code in sound driver use lots of cv_broadcast >> call(), it does not raise thread priority, this causes the music player >> does not have more chances to do I/O while other I/O bound applications >> will have. >> >> The kernel condition variable also causes top() to display incorrect >> priority because cv_wait does not update the priority but it is updated >> by cv_broadcastpri() which is too late for top to display. >> >> The kernel condition variable's initialization function should accept >> a thread priority parameter, and all thread sleep on the condition >> variable should use the priority. > > While your hypothesis of what is happening may be correct, I don't > think the solution is quite right. msleep() has to go away, at > least the priority parameter does. The kernel should be scheduling > based on thread priorities that are not artificially elevated by > parameters to msleep. > > The kernel CV and mutexes initialization functions should accept > something like Solaris interrupt cookies (see mutex_init() and > cv_init() in Solaris). All mutexes/CVs used by interrupt code > should initialize their CVs and mutexes with something like this. > I don't think they should be using a priority directly. > Oh, I don't want to change BSD's behavior, the FreeBSD in the past years does raise thread priority while sleeping, if msleep does not raise thread priority, I don't know if FreeBSD will still work as normal, by the way, your idea is a big change. Regards, David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 07:52:23 2007 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from miki (localhost [IPv6:::1]) by hub.freebsd.org (Postfix) with SMTP id E6BA016A41A; Fri, 21 Dec 2007 07:52:18 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Fri, 21 Dec 2007 15:51:23 +0800 From: Ariff Abdullah To: David Xu , Kuteynikov Dmitriy Message-Id: <20071221155123.53f593a2.ariff@FreeBSD.org> In-Reply-To: <476B6E35.508@freebsd.org> References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B6E35.508@freebsd.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__21_Dec_2007_15_51_23_+0800_Q5T_2.6JEVZ_20Yl" Cc: deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 07:52:23 -0000 --Signature=_Fri__21_Dec_2007_15_51_23_+0800_Q5T_2.6JEVZ_20Yl Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 21 Dec 2007 15:41:41 +0800 David Xu wrote: > Daniel Eischen wrote: > > On Fri, 21 Dec 2007, David Xu wrote: > >=20 > >> The kernel condition variable implementation is problematic, a > >> thread sleeping on a condition variable does not raise its > >priority > to some I/O priority, but most code will raise thread's > >priority to some > level with msleep(). The code in sound driver > >use lots of cv_broadcast > call(), it does not raise thread > >priority, this causes the music player > does not have more chances > >to do I/O while other I/O bound applications > will have. > >> The critical that require raising the priority are using cv_broadcastpri(), not cv_broadcast(). See sys/dev/sound/pcm/channel.h . > >> The kernel condition variable also causes top() to display > >incorrect > priority because cv_wait does not update the priority > >but it is updated > by cv_broadcastpri() which is too late for top > >to display. > > >> The kernel condition variable's initialization function should > >accept > a thread priority parameter, and all thread sleep on the > >condition > variable should use the priority. > >=20 > > While your hypothesis of what is happening may be correct, I don't > > think the solution is quite right. msleep() has to go away, at > > least the priority parameter does. The kernel should be > > scheduling based on thread priorities that are not artificially > > elevated by parameters to msleep. > >=20 > > The kernel CV and mutexes initialization functions should accept > > something like Solaris interrupt cookies (see mutex_init() and > > cv_init() in Solaris). All mutexes/CVs used by interrupt code > > should initialize their CVs and mutexes with something like this. > > I don't think they should be using a priority directly. > >=20 >=20 > Oh, I don't want to change BSD's behavior, the FreeBSD in the past > years does raise thread priority while sleeping, if msleep does not > raise thread priority, I don't know if FreeBSD will still work as > normal, by the way, your idea is a big change. >=20 With all due respect, the original poster issue are more to fluxbox non-opaque window dragging implementation which require locking the entire X server through XGrab/UngrabServer(), which in turns preventing other client windows to update their own gui, blocking the entire client operation. It has little or nothing to do with threading. Kuteynikov, go to fluxbox menu, and enable "Opaque Window Moving/Dragging/Resizing" (or whatever it is). -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Fri__21_Dec_2007_15_51_23_+0800_Q5T_2.6JEVZ_20Yl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHa3B7lr+deMUwTNoRAvZ3AKCgdJLyapGLqNu2+T/zjSSSh3furwCgr53W iYBPzBcw+MtyanBXpRA5HBU= =rcKN -----END PGP SIGNATURE----- --Signature=_Fri__21_Dec_2007_15_51_23_+0800_Q5T_2.6JEVZ_20Yl-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 07:52:53 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C94A16A417; Fri, 21 Dec 2007 07:52:53 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A44D913C45A; Fri, 21 Dec 2007 07:52:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lBL7qpks016607; Fri, 21 Dec 2007 02:52:51 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 21 Dec 2007 02:52:51 -0500 (EST) Date: Fri, 21 Dec 2007 02:52:51 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <476B6E35.508@freebsd.org> Message-ID: References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B6E35.508@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 07:52:53 -0000 On Fri, 21 Dec 2007, David Xu wrote: > Daniel Eischen wrote: >> On Fri, 21 Dec 2007, David Xu wrote: >> >>> The kernel condition variable implementation is problematic, a >>> thread sleeping on a condition variable does not raise its priority >>> to some I/O priority, but most code will raise thread's priority to some >>> level with msleep(). The code in sound driver use lots of cv_broadcast >>> call(), it does not raise thread priority, this causes the music player >>> does not have more chances to do I/O while other I/O bound applications >>> will have. >>> >>> The kernel condition variable also causes top() to display incorrect >>> priority because cv_wait does not update the priority but it is updated >>> by cv_broadcastpri() which is too late for top to display. >>> >>> The kernel condition variable's initialization function should accept >>> a thread priority parameter, and all thread sleep on the condition >>> variable should use the priority. >> >> While your hypothesis of what is happening may be correct, I don't >> think the solution is quite right. msleep() has to go away, at >> least the priority parameter does. The kernel should be scheduling >> based on thread priorities that are not artificially elevated by >> parameters to msleep. >> >> The kernel CV and mutexes initialization functions should accept >> something like Solaris interrupt cookies (see mutex_init() and >> cv_init() in Solaris). All mutexes/CVs used by interrupt code >> should initialize their CVs and mutexes with something like this. >> I don't think they should be using a priority directly. >> > > Oh, I don't want to change BSD's behavior, the FreeBSD in the past years > does raise thread priority while sleeping, if msleep does not raise > thread priority, I don't know if FreeBSD will still work as normal, by > the way, your idea is a big change. I don't think it is as big a change as you think it is. We already have several layers of priorities (interrupt, time-share, idle, ?). All threads belong to these classes. As long as priority inheritence works, there should be no problems. The problems seem to occur when we try to inject artificial priorities into threads, like using msleep(). I think we are better off just letting threads run based on their own base priority and whatever their inherited priority is. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 08:07:20 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C24E816A417; Fri, 21 Dec 2007 08:07:20 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B542613C457; Fri, 21 Dec 2007 08:07:20 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBL87H0w051537; Fri, 21 Dec 2007 08:07:19 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476B7476.3010509@freebsd.org> Date: Fri, 21 Dec 2007 16:08:22 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Daniel Eischen References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B6E35.508@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 08:07:20 -0000 Daniel Eischen wrote: > I don't think it is as big a change as you think it is. We already > have several layers of priorities (interrupt, time-share, idle, ?). > All threads belong to these classes. As long as priority inheritence > works, there should be no problems. The problems seem to occur when > we try to inject artificial priorities into threads, like using > msleep(). I think we are better off just letting threads run based > on their own base priority and whatever their inherited priority is. > For test purpose, you may try to ignore thread priority parameter in msleep(), I didn't test this, but it does change the FreeBSD behavior. I don't know any side effect since I am unable to test all applications in the world, maybe you can start a project to hack it ? Regards, David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 08:10:25 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C25F916A41A; Fri, 21 Dec 2007 08:10:25 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B3F0513C43E; Fri, 21 Dec 2007 08:10:25 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBL8ALAQ052474; Fri, 21 Dec 2007 08:10:23 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476B752E.8030101@freebsd.org> Date: Fri, 21 Dec 2007 16:11:26 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Ariff Abdullah References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B6E35.508@freebsd.org> <20071221155123.53f593a2.ariff@FreeBSD.org> In-Reply-To: <20071221155123.53f593a2.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: deischen@FreeBSD.org, Kuteynikov Dmitriy , freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 08:10:25 -0000 Ariff Abdullah wrote: > On Fri, 21 Dec 2007 15:41:41 +0800 > David Xu wrote: >> Daniel Eischen wrote: >>> On Fri, 21 Dec 2007, David Xu wrote: >>> >>>> The kernel condition variable implementation is problematic, a >>>> thread sleeping on a condition variable does not raise its >>> priority > to some I/O priority, but most code will raise thread's >>> priority to some > level with msleep(). The code in sound driver >>> use lots of cv_broadcast > call(), it does not raise thread >>> priority, this causes the music player > does not have more chances >>> to do I/O while other I/O bound applications > will have. > The critical that require raising the priority are using > cv_broadcastpri(), not cv_broadcast(). See sys/dev/sound/pcm/channel.h > . I know there is cv_broadcastpri, but I still think code in kernel should run first. :-) > > With all due respect, the original poster issue are more to fluxbox > non-opaque window dragging implementation which require locking the > entire X server through XGrab/UngrabServer(), which in turns > preventing other client windows to update their own gui, blocking the > entire client operation. It has little or nothing to do with > threading. > > Kuteynikov, go to fluxbox menu, and enable > "Opaque Window Moving/Dragging/Resizing" (or whatever it is). > OK. > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 08:16:17 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60AA716A468; Fri, 21 Dec 2007 08:16:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 275FD13C442; Fri, 21 Dec 2007 08:16:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lBL8GGaj024604; Fri, 21 Dec 2007 03:16:16 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 21 Dec 2007 03:16:16 -0500 (EST) Date: Fri, 21 Dec 2007 03:16:15 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <476B7476.3010509@freebsd.org> Message-ID: References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B6E35.508@freebsd.org> <476B7476.3010509@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 08:16:17 -0000 On Fri, 21 Dec 2007, David Xu wrote: > Daniel Eischen wrote: > >> I don't think it is as big a change as you think it is. We already >> have several layers of priorities (interrupt, time-share, idle, ?). >> All threads belong to these classes. As long as priority inheritence >> works, there should be no problems. The problems seem to occur when >> we try to inject artificial priorities into threads, like using >> msleep(). I think we are better off just letting threads run based >> on their own base priority and whatever their inherited priority is. >> > > For test purpose, you may try to ignore thread priority parameter > in msleep(), I didn't test this, but it does change the FreeBSD > behavior. I don't know any side effect since I am unable to test > all applications in the world, maybe you can start a project to hack > it ? I'll take a look at trying that. I should be able to figure out how to get msleep to ignore the priority. But I think the missing piece is the interrupt routines - they need to create their mutexes and CVs so that they are more like priority ceiling mutexes. Any thread (even non-interrupt threads) that takes one of these mutexes needs to have its priority raised as well as blocking the interrupt (for fast interrupts anyway) until the mutex is released. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 08:25:04 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E8C16A41A; Fri, 21 Dec 2007 08:25:04 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3297D13C447; Fri, 21 Dec 2007 08:25:04 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBL8P1QF065684; Fri, 21 Dec 2007 08:25:02 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476B789E.4040009@freebsd.org> Date: Fri, 21 Dec 2007 16:26:06 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Daniel Eischen References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B6E35.508@freebsd.org> <476B7476.3010509@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 08:25:04 -0000 Daniel Eischen wrote: > On Fri, 21 Dec 2007, David Xu wrote: > >> Daniel Eischen wrote: >> >>> I don't think it is as big a change as you think it is. We already >>> have several layers of priorities (interrupt, time-share, idle, ?). >>> All threads belong to these classes. As long as priority inheritence >>> works, there should be no problems. The problems seem to occur when >>> we try to inject artificial priorities into threads, like using >>> msleep(). I think we are better off just letting threads run based >>> on their own base priority and whatever their inherited priority is. >>> >> >> For test purpose, you may try to ignore thread priority parameter >> in msleep(), I didn't test this, but it does change the FreeBSD >> behavior. I don't know any side effect since I am unable to test >> all applications in the world, maybe you can start a project to hack >> it ? > > I'll take a look at trying that. I should be able to figure out > how to get msleep to ignore the priority. But I think the missing > piece is the interrupt routines - they need to create their mutexes > and CVs so that they are more like priority ceiling mutexes. Any > thread (even non-interrupt threads) that takes one of these mutexes > needs to have its priority raised as well as blocking the interrupt > (for fast interrupts anyway) until the mutex is released. > kernel mutex is already priority inheritence, the spin lock mutex looks like a priority protected mutex which raises thread priority to highest possible(critical section), and can not be preempted. so there is no priority problem in mutex. The only problem I can think of is semaphore-like msleep/wakeup pair which does not do priority inheritance, if a higher priority thread is blocked in msleep, priority of another thread holding the resources is not boosted. From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 18:53:22 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA75816A41A; Fri, 21 Dec 2007 18:53:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC9D13C46A; Fri, 21 Dec 2007 18:53:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 225455899-1834499 for multiple; Fri, 21 Dec 2007 13:35:14 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBLIarwR088679; Fri, 21 Dec 2007 13:37:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-threads@freebsd.org, Daniel Eischen Date: Fri, 21 Dec 2007 13:36:44 -0500 User-Agent: KMail/1.9.6 References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B7476.3010509@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712211336.44996.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 21 Dec 2007 13:37:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5208/Fri Dec 21 12:02:14 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: David Xu Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 18:53:22 -0000 On Friday 21 December 2007 03:16:15 am Daniel Eischen wrote: > On Fri, 21 Dec 2007, David Xu wrote: > > > Daniel Eischen wrote: > > > >> I don't think it is as big a change as you think it is. We already > >> have several layers of priorities (interrupt, time-share, idle, ?). > >> All threads belong to these classes. As long as priority inheritence > >> works, there should be no problems. The problems seem to occur when > >> we try to inject artificial priorities into threads, like using > >> msleep(). I think we are better off just letting threads run based > >> on their own base priority and whatever their inherited priority is. > >> > > > > For test purpose, you may try to ignore thread priority parameter > > in msleep(), I didn't test this, but it does change the FreeBSD > > behavior. I don't know any side effect since I am unable to test > > all applications in the world, maybe you can start a project to hack > > it ? > > I'll take a look at trying that. I should be able to figure out > how to get msleep to ignore the priority. But I think the missing > piece is the interrupt routines - they need to create their mutexes > and CVs so that they are more like priority ceiling mutexes. Any > thread (even non-interrupt threads) that takes one of these mutexes > needs to have its priority raised as well as blocking the interrupt > (for fast interrupts anyway) until the mutex is released. One issue is that some places actually use the sleep priority for other decisions. (For example, we dont' swap out threads at PSOCK or higher.) You'd need to fix this logic in another way. Solaris also bumps the priority of threads that acquire a read lock on a rwlock to a kernel-level priority to work around lack of priority propagation for readers. An alernative to that is to bump the priority of threads that are in the kernel to a kernel-level priority on kernel-entry, but then you have to be careful about threads that are just waiting for the CPU and not a lock or other resource or all threads will effectively be scheduled at kernel-level priorities. One thing I have wanted to do as a small step is to add a sched_sleep_prio() for the msleep(9) priority (along iwth a get_sleep_prio() or some such for places that want to check PSOCK) and let the scheduler factor that into the actual priority but don't enforce that the msleep(9) arg actually sets the priority. I do think cv's don't need to have priorities. I'm not sure that mutexes for drivers need priorities as in Solaris since priority propogation should already handle that case if the mutex is needed by an ithread. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Fri Dec 21 20:17:19 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1B0F16A41B; Fri, 21 Dec 2007 20:17:19 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A552413C46A; Fri, 21 Dec 2007 20:17:19 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (ariff@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBLKHJEj070094; Fri, 21 Dec 2007 20:17:19 GMT (envelope-from ariff@freefall.freebsd.org) Received: (from ariff@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBLKHJSa070090; Fri, 21 Dec 2007 20:17:19 GMT (envelope-from ariff) Date: Fri, 21 Dec 2007 20:17:19 GMT Message-Id: <200712212017.lBLKHJSa070090@freefall.freebsd.org> To: kuteynikov@gmail.com, ariff@FreeBSD.org, freebsd-threads@FreeBSD.org From: ariff@FreeBSD.org Cc: Subject: Re: threads/118910: Multithreading problem 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, 21 Dec 2007 20:17:20 -0000 Synopsis: Multithreading problem State-Changed-From-To: open->closed State-Changed-By: ariff State-Changed-When: Fri Dec 21 20:16:43 UTC 2007 State-Changed-Why: The submitter agrees that the issue has been solved and has nothing to do with multithreading. Brief solution can be found here: http://lists.freebsd.org/pipermail/freebsd-threads/2007-December/004087.html http://www.freebsd.org/cgi/query-pr.cgi?pr=118910