From owner-freebsd-threads@FreeBSD.ORG Sun Nov 30 03:07:11 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F00316A4CE; Sun, 30 Nov 2003 03:07:11 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-121-163-164.dsl.pltn13.pacbell.net [68.121.163.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 761C143FEA; Sun, 30 Nov 2003 03:07:10 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.9/8.12.9) with ESMTP id hAUB4gen034956; Sun, 30 Nov 2003 03:04:42 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id hAUB4fe1034955; Sun, 30 Nov 2003 03:04:41 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Sun, 30 Nov 2003 03:04:41 -0800 From: David Schultz To: Jay Sern Liew Message-ID: <20031130110441.GA34017@VARK.homeunix.com> Mail-Followup-To: Jay Sern Liew , freebsd-threads@FreeBSD.ORG References: <20031129183810.M90959@pinnacle.schulte.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129183810.M90959@pinnacle.schulte.org> cc: freebsd-threads@FreeBSD.ORG Subject: Re: thread/process & memory management source code X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 11:07:11 -0000 [Redirected to threads@; please avoid spamming multiple lists.] On Sat, Nov 29, 2003, Jay Sern Liew wrote: > Can someone point to me the specific location in the FreeBSD kernel source > where the code for FreeBSD's thread/process & memory management are? > > Specifically, where the dispatcher and scheduler is implemented, > what kind of scheduling algorithms(short term, long term) are used, > where the dynamic storage allocation algorithm is implemented(I'll try > to figure the algorithm used from the code), etc. For short term scheduling, FreeBSD uses the standard Unix decay-usage priority scheduling. There is also an experimental scheduler called ULE, which is designed to work better on SMPs. ULE uses an ad hoc idea about how ``interactive'' a process is in order to make scheduling decisions. See kern_switch.c, sched_4bsd.c, sched_ule.c in src/sys/kern. Long term scheduling is less important than it used to be, but FreeBSD has a swapout daemon that kicks in when the system can't recover enough memory by paging alone. It will basically swap out every process it can that is idle and hasn't already been swapped out recently. Swapping in occurs according in the order of a priority that is based on the interactivity of the process, the time it has been swapped out, and its nice value. See src/sys/vm/vm_glue.c. The primary kernel memory allocator is a slab allocator. See src/sys/vm/uma_*.c, src/sys/kern/kern_malloc.c, and http://citeseer.nj.nec.com/bonwick94slab.html. From owner-freebsd-threads@FreeBSD.ORG Sun Nov 30 06:10:12 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8397116A4CE; Sun, 30 Nov 2003 06:10:12 -0800 (PST) Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47A7543F85; Sun, 30 Nov 2003 06:10:11 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (excluster2.maxwell.syr.edu [128.230.129.231]) by maxwell.syr.edu (8.12.10/8.9.1) with ESMTP id hAUEA9o2000703; Sun, 30 Nov 2003 09:10:09 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Nov 2003 09:10:10 -0500 Message-ID: <32A8B2CB12BFC84D8D11D872C787AA9A515DB1@EXCHANGE.forest.maxwell.syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KSE system scope vs non system scope threads Thread-Index: AcO3CEv0fETnxaVfRteW3OuPklomtAAQlGfI From: "Christopher M. Sedore" To: cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 14:10:12 -0000 =20 ________________________________ From: Daniel Eischen [mailto:eischen@vigrid.com] On Sat, 29 Nov 2003, Christopher M. Sedore wrote: [...] >> I ask this because I'm observing some behavior that I don't expect. = When >> running a threaded program with KSE and non-system-scope threads, I = see >> performance degradation in my network traffic when I'm attempting to = connect >> to remote hosts that are down. Libthr doesn't see this degradation, = and KSE >> with system-scope threads doesn't perform as well as libthr, but is = much >> closer. > >Define what you think is degradation. Process scope threads run in the >same KSEG. They are all kept in the same priority-based run-queue. >If you have other threads that have equal or higher priority than >the network threads in question, they will/may run before those >threads. All it takes is one thread that doesn't block (CPU-bound) >to eat away at the time allotment for your other threads. > >If a remote host is down and a thread can't connect to it, that thread >should block allowing other threads to run. Are you using blocking >or non-blocking connects? I'm using blocking connects. Degradation is I should be moving = ~5-7MB/sec (and I do if I don't try to connect to any hosts that are = down). Once I do, I see fluctuations from ~15-20KB/sec (note: KB) to = 3-5MB/sec, somewhat associated with when the connects happen. Running = libthr, I move 6-7MB/sec consistently (until everything hangs up showing = sigwait as the status in top, anyway). System scope threads turn in = numbers from 5-6MB/sec. (Note I don't have any hang problems under KSE, = only libthr.) =20 On Monday I'm going to try David Xu's suggestion of trying v1.18 of = thr_spinlock.c to see if that helps. -Chris From owner-freebsd-threads@FreeBSD.ORG Sun Nov 30 06:43:09 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6110316A4CE for ; Sun, 30 Nov 2003 06:43:09 -0800 (PST) Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 272ED43FDF for ; Sun, 30 Nov 2003 06:43:08 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (excluster2.maxwell.syr.edu [128.230.129.231]) by maxwell.syr.edu (8.12.10/8.9.1) with ESMTP id hAUEh5o2001966; Sun, 30 Nov 2003 09:43:05 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Nov 2003 09:43:05 -0500 Message-ID: <32A8B2CB12BFC84D8D11D872C787AA9A02B1F78F@EXCHANGE.forest.maxwell.syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KSE system scope vs non system scope threads Thread-Index: AcO3Aqh0vQV4KxbwSEGxXvEbfrq+WAASxhyj From: "Christopher M. Sedore" To: "Jeff Roberson" cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 14:43:09 -0000 From: Jeff Roberson [mailto:jroberson@chesapeake.net] >> I ask this because I'm observing some behavior that I don't expect. = >> When running a threaded program with KSE and non-system-scope=20 >> threads, I see performance degradation in my network traffic when I'm >> attempting to connect to remote hosts that are down. Libthr doesn't >> see this degradation, and KSE with system-scope threads doesn't >> perform as well as libthr, but is much closer. > >Can you describe the threaded application some? For certain types of >tasks thr is likely to remain faster due to its simplicity. I'm mostly >just curious to hear what your observations are. Sure--I'm working on Usenet news transit software. Basically, inbound = connections offering articles to the host and outbound connections = offering the articles to other hosts. Inbound data rates are usually in = the 6-10MB/sec range (much higher if you have a backlog of articles), = outbound rates depend on the number of peers you have. In testing thus = far, I've been pushing 30MB/sec with my current code. Thus far, libthr = is fastest based on external benchmarks. =20 =20 I think libthr may have a bug related to synchronization somewhere, = though. After some random period, threads hang in sigwait (according to = top). From what I've observed, everything is fine, then one thread = hangs, then shortly thereafter the rest do (actually not all the rest, = but any that content for mutexes do). Since I don't see these hangs = with KSE or libc_r, I've blindly assumed that the problem is with libthr = rather than my code. =20 -Chris From owner-freebsd-threads@FreeBSD.ORG Sun Nov 30 06:45:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A604716A4CE for ; Sun, 30 Nov 2003 06:45:04 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92B3843FD7 for ; Sun, 30 Nov 2003 06:45:03 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hAUEj21G007496; Sun, 30 Nov 2003 09:45:02 -0500 (EST) Date: Sun, 30 Nov 2003 09:45:02 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: "Christopher M. Sedore" In-Reply-To: <32A8B2CB12BFC84D8D11D872C787AA9A515DB1@EXCHANGE.forest.maxwell.syr.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 14:45:04 -0000 On Sun, 30 Nov 2003, Christopher M. Sedore wrote: > > From: Daniel Eischen [mailto:eischen@vigrid.com] > > > >Define what you think is degradation. Process scope threads run in the > >same KSEG. They are all kept in the same priority-based run-queue. > >If you have other threads that have equal or higher priority than > >the network threads in question, they will/may run before those > >threads. All it takes is one thread that doesn't block (CPU-bound) > >to eat away at the time allotment for your other threads. > > > >If a remote host is down and a thread can't connect to it, that thread > >should block allowing other threads to run. Are you using blocking > >or non-blocking connects? > > I'm using blocking connects. Degradation is I should be moving ~5-7MB/sec > (and I do if I don't try to connect to any hosts that are down). Once I do, > I see fluctuations from ~15-20KB/sec (note: KB) to 3-5MB/sec, somewhat > associated with when the connects happen. Running libthr, I move 6-7MB/sec > consistently (until everything hangs up showing sigwait as the status in > top, anyway). System scope threads turn in numbers from 5-6MB/sec. (Note I > don't have any hang problems under KSE, only libthr.) > > On Monday I'm going to try David Xu's suggestion of trying v1.18 of > thr_spinlock.c to see if that helps. You should configure your mailer to wrap lines on outgoing mail... Are you using cancellation at all? I just noticed that libkse doesn't seem to have a cancellation point for connect(). Are you doing anything in signal handlers that you shouldn't be doing? Other than that, it sounds like a locking problem in the kernel. A thread blocked in connect() in the kernel shouldn't prevent upcalls allowing other threads to run. It sounds like the upcalls aren't happening... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Nov 30 15:14:42 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A872516A4CE; Sun, 30 Nov 2003 15:14:42 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5C4443F85; Sun, 30 Nov 2003 15:14:41 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAUNEeFY090085; Sun, 30 Nov 2003 15:14:41 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <3FCA7C86.6000800@freebsd.org> Date: Mon, 01 Dec 2003 07:25:58 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031025 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christopher M. Sedore" References: <32A8B2CB12BFC84D8D11D872C787AA9A515DB1@EXCHANGE.forest.maxwell.syr.edu> In-Reply-To: <32A8B2CB12BFC84D8D11D872C787AA9A515DB1@EXCHANGE.forest.maxwell.syr.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: deischen@freebsd.org cc: threads@freebsd.org Subject: Re: KSE system scope vs non system scope threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 23:14:42 -0000 Christopher M. Sedore wrote: >I'm using blocking connects. Degradation is I should be moving ~5-7MB/sec (and I do if I don't try to connect to any hosts that are down). Once I do, I see fluctuations from ~15-20KB/sec (note: KB) to 3-5MB/sec, somewhat associated with when the connects happen. Running libthr, I move 6-7MB/sec consistently (until everything hangs up showing sigwait as the status in top, anyway). System scope threads turn in numbers from 5-6MB/sec. (Note I don't have any hang problems under KSE, only libthr.) > >On Monday I'm going to try David Xu's suggestion of trying v1.18 of thr_spinlock.c to see if that helps. > > > I don't know if you hit a hard limit in kernel. The hard limit is sysctl kern.threads.max_threads_per_proc, default is 150, it means system only allows 150 threads to be blocked in kernel, if you hit the limits, then performance will be degraded. David Xu >-Chris >_______________________________________________ >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 Sun Nov 30 17:17:57 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 578CA16A4CE; Sun, 30 Nov 2003 17:17:57 -0800 (PST) Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id E66EF43FDD; Sun, 30 Nov 2003 17:17:55 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (excluster2.maxwell.syr.edu [128.230.129.231]) by maxwell.syr.edu (8.12.10/8.9.1) with ESMTP id hB11Hro2027549; Sun, 30 Nov 2003 20:17:53 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Nov 2003 20:17:22 -0500 Message-ID: <32A8B2CB12BFC84D8D11D872C787AA9A02B1F790@EXCHANGE.forest.maxwell.syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KSE system scope vs non system scope threads Thread-Index: AcO3l9jqSQ61H2U/SEeUZ/pS/iRNgQAEQYyi From: "Christopher M. Sedore" To: "David Xu" cc: deischen@freebsd.org cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2003 01:17:57 -0000 I don't presently have more than 20-30 threads running at any one time. =20 -Chris ________________________________ From: David Xu [mailto:davidxu@freebsd.org] Sent: Sun 11/30/2003 6:25 PM To: Christopher M. Sedore Cc: deischen@freebsd.org; threads@freebsd.org Subject: Re: KSE system scope vs non system scope threads Christopher M. Sedore wrote: >I'm using blocking connects. Degradation is I should be moving = ~5-7MB/sec (and I do if I don't try to connect to any hosts that are = down). Once I do, I see fluctuations from ~15-20KB/sec (note: KB) to = 3-5MB/sec, somewhat associated with when the connects happen. Running = libthr, I move 6-7MB/sec consistently (until everything hangs up showing = sigwait as the status in top, anyway). System scope threads turn in = numbers from 5-6MB/sec. (Note I don't have any hang problems under KSE, = only libthr.) > >On Monday I'm going to try David Xu's suggestion of trying v1.18 of = thr_spinlock.c to see if that helps. > >=20 > I don't know if you hit a hard limit in kernel. The hard limit is sysctl kern.threads.max_threads_per_proc, default is 150, it means system only allows 150 threads to be blocked in kernel, if you hit the limits, then performance will be degraded. David Xu >-Chris >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to = "freebsd-threads-unsubscribe@freebsd.org" > >=20 > From owner-freebsd-threads@FreeBSD.ORG Mon Dec 1 11:04:44 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 935F616A4CE for ; Mon, 1 Dec 2003 11:04:44 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD05244037 for ; Mon, 1 Dec 2003 11:01:36 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hB1J1aFY015860 for ; Mon, 1 Dec 2003 11:01:36 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hB1J1Z6O015854 for freebsd-threads@freebsd.org; Mon, 1 Dec 2003 11:01:35 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Dec 2003 11:01:35 -0800 (PST) Message-Id: <200312011901.hB1J1Z6O015854@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 Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2003 19:04:44 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2002/01/16] kern/33951 threads pthread_cancel is ignored 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/04/02] bin/26307 threads libc_r aborts when using the KDE media pl o [2001/10/31] bin/31661 threads pthread_kill signal handler doesn't get s o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/03/07] bin/35622 threads sigaltstack is missing in libc_r o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2002/10/10] kern/43887 threads abnormal CPU useage when use pthread_mute o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled o [2003/05/30] kern/52817 threads top(1) shows garbage for threaded process 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri o [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 09:51:44 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AE6C16A4CE for ; Sat, 6 Dec 2003 09:51:44 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45A7143FF2 for ; Sat, 6 Dec 2003 09:51:42 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id hB6HpeWU003359 for ; Sat, 6 Dec 2003 20:51:40 +0300 (MSK) (envelope-from is@rambler-co.ru) Date: Sat, 6 Dec 2003 20:51:40 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2003 17:51:44 -0000 The current pthread_mutex_trylock() implementation in both libpthread (libkse) and libthr can block if mutex is locked by another thread. libphtread calls THR_LOCK_ACQUIRE() and it can be blocked. libthr's pthread_mutex_trylock() is too heavy - it calls 3 syscalls: sigprocmask()/umtx_lock()/sigprocmask() and can be blocked too. SUSv2 states: [ http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutex_lock.html ] -------- The function pthread_mutex_trylock() is identical to pthread_mutex_lock() except that if the mutex object referenced by mutex is currently locked (by any thread, including the current thread), the call returns immediately. [ ... ] The pthread_mutex_trylock() function will fail if: [EBUSY] The mutex could not be acquired because it was already locked. [ ... ] The pthread_mutex_lock() function may fail if: [EDEADLK] The current thread already owns the mutex. -------- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 10:24:41 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BABB16A4CE for ; Sat, 6 Dec 2003 10:24:41 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A52943FD7 for ; Sat, 6 Dec 2003 10:24:40 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hB6IOdml018231; Sat, 6 Dec 2003 13:24:39 -0500 (EST) Date: Sat, 6 Dec 2003 13:24:39 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Igor Sysoev In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2003 18:24:41 -0000 On Sat, 6 Dec 2003, Igor Sysoev wrote: > The current pthread_mutex_trylock() implementation in both libpthread (libkse) > and libthr can block if mutex is locked by another thread. > > libphtread calls THR_LOCK_ACQUIRE() and it can be blocked. That's an implementation detail. Threads release the low-level lock (THR_LOCK_ACQUIRE/THR_LOCK_RELEASE) after they take the mutex. I don't believe we (libpthread) are conflicting with POSIX in this respect. > libthr's pthread_mutex_trylock() is too heavy - it calls 3 syscalls: > sigprocmask()/umtx_lock()/sigprocmask() and can be blocked too. > > > SUSv2 states: > [ http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutex_lock.html ] > > -------- > The function pthread_mutex_trylock() is identical to pthread_mutex_lock() > except that if the mutex object referenced by mutex is currently locked > (by any thread, including the current thread), the call returns immediately. The low-level locks are necessary (at least in libpthread implementation) to safely test the mutex for ownership. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 10:40:07 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFBAD16A4CF; Sat, 6 Dec 2003 10:40:07 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ACAF43FBF; Sat, 6 Dec 2003 10:40:06 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hB6Ie5ml021190; Sat, 6 Dec 2003 13:40:05 -0500 (EST) Date: Sat, 6 Dec 2003 13:40:05 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: deischen@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2003 18:40:08 -0000 On Sat, 6 Dec 2003, Daniel Eischen wrote: > On Sat, 6 Dec 2003, Igor Sysoev wrote: > > > > SUSv2 states: > > [ http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutex_lock.html ] > > > > -------- > > The function pthread_mutex_trylock() is identical to pthread_mutex_lock() > > except that if the mutex object referenced by mutex is currently locked > > (by any thread, including the current thread), the call returns immediately. > > The low-level locks are necessary (at least in libpthread implementation) > to safely test the mutex for ownership. And not only that, but the low-level locks are also necessary to take the mutex if it is not owned. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 13:12:10 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0458C16A4CF for ; Sat, 6 Dec 2003 13:12:10 -0800 (PST) Received: from owl.melbpc.org.au (owl.melbpc.org.au [203.12.152.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A1DC43FEA for ; Sat, 6 Dec 2003 13:12:06 -0800 (PST) (envelope-from kpeter@melbpc.org.au) Received: from 127.0.0.1 (localhost.melbpc.org.au [127.0.0.1]) by av.domain.name (Postfix) with SMTP id 9A83D535D for ; Sun, 7 Dec 2003 08:12:04 +1100 (EST) Received: by owl.melbpc.org.au (Postfix, from userid 1005) id 91CC65337; Sun, 7 Dec 2003 08:12:04 +1100 (EST) Received: from melbpc.org.au (dsl-47.42.221.203.lns02-dryb-mel.dsl.comindico.com.au [203.221.42.47]) by owl.melbpc.org.au (Postfix) with ESMTP id DD85F5392 for ; Sun, 7 Dec 2003 08:11:31 +1100 (EST) Message-ID: <3FD245FF.3040003@melbpc.org.au> Date: Sun, 07 Dec 2003 08:11:27 +1100 From: Peter Kostouros Organization: Melbourne PC User Group User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: threads@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-15.4 required=8.0 tests=AWL,BAYES_00,SIGNATURE_SHORT_SPARSE,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kpeter@melbpc.org.au List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2003 21:12:10 -0000 Hi I have been tracking mozilla (cvs) that terminates when linked against libkse: basically a routine checks whether a mutex variable is locked with a call to pthread_mutex_trylock() before it attempts to unlock it with pthread_mutex_unlock(). The return value of pthread_mutex_trylock is checked against EBUSY and terminates the process if it is otherwise. In my particular scenario, pthread_mutex_trylock() returns EDEADLK: the pthread_mutex_trylock man page does not mention EDEADLK as an error code. When the application is linked against libc_r or libthr, pthread_mutex_trylock returns EBUSY in the scenario described above. I suppose my question is how do you safely (and quickly) check the state of a mutex variable? Note, I am running FreeBSD 5.2-BETA i386 with SCHED_ULE. -- Regards Peter As always the organisation disavows knowledge of this email From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 17:14:54 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6EE216A4CE; Sat, 6 Dec 2003 17:14:54 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B9BD43F75; Sat, 6 Dec 2003 17:14:54 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hB71EqFY066062; Sat, 6 Dec 2003 17:14:53 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <3FD27FC3.6020100@freebsd.org> Date: Sun, 07 Dec 2003 09:17:55 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031206 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: deischen@freebsd.org cc: threads@freebsd.org Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2003 01:14:54 -0000 Daniel Eischen wrote: >On Sat, 6 Dec 2003, Daniel Eischen wrote: > > > >>On Sat, 6 Dec 2003, Igor Sysoev wrote: >> >> >>>SUSv2 states: >>>[ http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutex_lock.html ] >>> >>>-------- >>>The function pthread_mutex_trylock() is identical to pthread_mutex_lock() >>>except that if the mutex object referenced by mutex is currently locked >>>(by any thread, including the current thread), the call returns immediately. >>> >>> >>The low-level locks are necessary (at least in libpthread implementation) >>to safely test the mutex for ownership. >> >> > >And not only that, but the low-level locks are also necessary to take >the mutex if it is not owned. > > > In libkse, if a thread is in critical region, scheduler will let it run until it leaves critical region unless it is blocked in kernel or volunteerly switchouts itself. In the case you are talking about, the thread will never be blocked on a UP machine. This only happens under SMP. David Xu