From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 05:58:03 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 C09D137B401 for ; Mon, 7 Jul 2003 05:58:03 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9418A43FCB for ; Mon, 7 Jul 2003 05:58:02 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h67CvxsL010162 for ; Mon, 7 Jul 2003 15:58:01 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F096E56.4010609@he.iki.fi> Date: Mon, 07 Jul 2003 15:57:58 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: thread scheduling priority 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, 07 Jul 2003 12:58:04 -0000 I have two threads on a SMP (2 CPU, HT disabled) box with world+kernel from mid-June. (cvsupping to latest right now) and a process which runs two threads with the following code snippet, more or less in a process & maintenance (collecting statistics, doing housekeeping, etc.) fashion. While the main thread does it's stuff it competes for a mutex with the other thread. However I'm observing that the thread created in the snippet below has hard time getting scheduled while the main thread is running. Am I missing something? No rtprio stuff here, contention scope is the default. { struct sched_param param; pthread_attr_t attributes; pthread_attr_init (&attributes); pthread_attr_getschedparam (&attributes,¶m); param.sched_priority += 5; pthread_attr_setschedparam (&attributes,¶m); pthread_create (&smem_thread,&attributes,&live_poll_sharedmem,0); } Pete From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 07:14: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 4241937B401 for ; Mon, 7 Jul 2003 07:14:04 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 965D143F75 for ; Mon, 7 Jul 2003 07:14:03 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h67EE2AI006639; Mon, 7 Jul 2003 10:14:02 -0400 (EDT) Date: Mon, 7 Jul 2003 10:14:02 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <3F096E56.4010609@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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, 07 Jul 2003 14:14:04 -0000 On Mon, 7 Jul 2003, Petri Helenius wrote: > I have two threads on a SMP (2 CPU, HT disabled) box with world+kernel > from mid-June. (cvsupping to latest right now) and a process which > runs two threads with the following code snippet, more or less in a process > & maintenance (collecting statistics, doing housekeeping, etc.) fashion. > While > the main thread does it's stuff it competes for a mutex with the other > thread. However > I'm observing that the thread created in the snippet below has hard time > getting > scheduled while the main thread is running. First, you should say what threading library you are using. I'll answer assuming you are using libkse (if you aren't, ignore me). Try forcing libkse to use one KSE. By default, libkse will create as many KSEs as CPUs that you have. It is possible that there is a problem with trying to keep both KSEs active when you only have 2 threads and one or more of them block or sleep. To do this, set kern.threads.debug=1 and kern.threads.virtual_cpu=1: # sysctl kern.threads.debug=1 # sysctl kern.threads.virtual_cpu=1 Also, the default scheduling policy is SCHED_RR and the RR interval is 20msec. If your main thread is in a busy loop, no other threads will run for 20 or so msec (assuming 1 KSE). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 07:37: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 6BF4437B401 for ; Mon, 7 Jul 2003 07:37:10 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B87143F93 for ; Mon, 7 Jul 2003 07:37:09 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h67Eb7sL010840; Mon, 7 Jul 2003 17:37:07 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F098593.8090605@he.iki.fi> Date: Mon, 07 Jul 2003 17:37:07 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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, 07 Jul 2003 14:37:10 -0000 Daniel Eischen wrote: >First, you should say what threading library you are using. >I'll answer assuming you are using libkse (if you aren't, ignore me). > > I'll blame the heat for not mentioning that :-) Yes, I'm using libkse. >Try forcing libkse to use one KSE. By default, libkse will >create as many KSEs as CPUs that you have. It is possible > Actually it seems that it creates double the amount, because of the HypeThreading junk, although I have the logical secondary cores halted. I still believe it's a mistake not to allow them to "go away" altogether but have them configured confusing things like system utilities and in this case, libkse; # sysctl kern.threads.virtual_cpu=1 kern.threads.virtual_cpu: 4 -> 1 >that there is a problem with trying to keep both KSEs active >when you only have 2 threads and one or more of them block >or sleep. To do this, set kern.threads.debug=1 and >kern.threads.virtual_cpu=1: > > # sysctl kern.threads.debug=1 > # sysctl kern.threads.virtual_cpu=1 > >Also, the default scheduling policy is SCHED_RR and the RR >interval is 20msec. If your main thread is in a busy loop, >no other threads will run for 20 or so msec (assuming 1 KSE). > > Is there a way to hand over the mutex to the other thread when it's unlocked by the main thread? pthread_yield? Is that a no-op if there is no other runnable thread? I'd rather have both threads running while they can, using both CPUs. I assume the "correct" setting for virtual_cpu in my case would be 2 ? Pete obviously the other option is to From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 07:58:01 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 A66DA37B405 for ; Mon, 7 Jul 2003 07:58:01 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B3E343F93 for ; Mon, 7 Jul 2003 07:58:00 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h67EvxAI013314; Mon, 7 Jul 2003 10:57:59 -0400 (EDT) Date: Mon, 7 Jul 2003 10:57:59 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <3F098593.8090605@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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: Mon, 07 Jul 2003 14:58:02 -0000 On Mon, 7 Jul 2003, Petri Helenius wrote: > Daniel Eischen wrote: > > >First, you should say what threading library you are using. > >I'll answer assuming you are using libkse (if you aren't, ignore me). > > > > > I'll blame the heat for not mentioning that :-) Yes, > I'm using libkse. > > >Try forcing libkse to use one KSE. By default, libkse will > >create as many KSEs as CPUs that you have. It is possible > > > Actually it seems that it creates double the amount, because of > the HypeThreading junk, although I have the logical secondary > cores halted. I still believe it's a mistake not to allow them to > "go away" altogether but have them configured confusing things > like system utilities and in this case, libkse; > # sysctl kern.threads.virtual_cpu=1 > kern.threads.virtual_cpu: 4 -> 1 > > >that there is a problem with trying to keep both KSEs active > >when you only have 2 threads and one or more of them block > >or sleep. To do this, set kern.threads.debug=1 and > >kern.threads.virtual_cpu=1: > > > > # sysctl kern.threads.debug=1 > > # sysctl kern.threads.virtual_cpu=1 > > > >Also, the default scheduling policy is SCHED_RR and the RR > >interval is 20msec. If your main thread is in a busy loop, > >no other threads will run for 20 or so msec (assuming 1 KSE). > > > > > Is there a way to hand over the mutex to the other thread when it's unlocked > by the main thread? pthread_yield? Is that a no-op if there is no other > runnable > thread? I'd rather have both threads running while they can, using both > CPUs. Mutexes are implemented using direct handoff (I think that's the term). Once a mutex is released, it is given to the next thread that is waiting on it and that thread is then marked runnable. Idle KSEs are suppose to be woken whenever there are runnable threads. For now, just see if things work better with 1 CPU defined. If not, then all this talk about multiple KSEs isn't your problem; it is something else. > I assume the "correct" setting for virtual_cpu in my case would be 2 ? It shouldn't matter. Libkse should do the right thing regardless of how many CPUs you have. In your case, there may be extra overhead with having only 2 threads. Both idling of a KSE and waking a KSE are system calls, whereas normal thread switches within the same KSE are not. Depending on how often your threads run and block, running those 2 threads on 2 KSEs may not be as efficient as running them with only 1 KSE. The way to set the number of KSEs allocated to run scope process threads is to use pthread_setconcurrency(). This currently can't be used to reduce the number of KSEs, but it is on our TODO list. Also, there is currently no way to tell libkse not to automatically create as many KSEs as defined by kern.threads.virtual_cpus. Perhaps we'll add an environment variable to do this. Perhaps we also need a better method of auto-tuning the number of KSEs. If KSEs are not utilizing much of their quantum and there is a lot of idling and waking of them, then we're better off with less of them. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 08:42:08 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 AE76937B401; Mon, 7 Jul 2003 08:42:08 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3090643F75; Mon, 7 Jul 2003 08:42:07 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h67Fg3sL011326; Mon, 7 Jul 2003 18:42:05 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F0994CB.6070403@he.iki.fi> Date: Mon, 07 Jul 2003 18:42:03 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: deischen@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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, 07 Jul 2003 15:42:09 -0000 Daniel Eischen wrote: >Mutexes are implemented using direct handoff (I think that's the >term). Once a mutex is released, it is given to the next thread >that is waiting on it and that thread is then marked runnable. >Idle KSEs are suppose to be woken whenever there are runnable >threads. > > So when the main thread unlocks the mutex there are two runnable threads, which one keeps running? >For now, just see if things work better with 1 CPU defined. >If not, then all this talk about multiple KSEs isn't your >problem; it is something else. > > It definetly runs a lot better, however not as good as I would expect if the running thread would be switched to the higher scheduling priority thread immediately on the mutex release. Should that happen or does it wait until the other thread hits a blocking condition ? > > >>I assume the "correct" setting for virtual_cpu in my case would be 2 ? >> >> > >It shouldn't matter. Libkse should do the right thing regardless >of how many CPUs you have. In your case, there may be extra >overhead with having only 2 threads. Both idling of a KSE and >waking a KSE are system calls, whereas normal thread switches >within the same KSE are not. Depending on how often your >threads run and block, running those 2 threads on 2 KSEs may >not be as efficient as running them with only 1 KSE. > > Unfortunately the code has not been designed with threads in mind initially so there is quite a large table protected with a mutex and the plan is to lock either each element or block of elements separately and have a significantly larger number of "worker threads" and as far as I understand there is not really an issue of having, say 65536 mutexes, as long as I keep the threads from running into locking ordering issues. (no performance issues, etc.) Dual-CPU is not really the target platform anyway, more like 4-8 way things where the benefits greatly outweigh the penalties. >The way to set the number of KSEs allocated to run scope >process threads is to use pthread_setconcurrency(). This >currently can't be used to reduce the number of KSEs, but >it is on our TODO list. Also, there is currently no way >to tell libkse not to automatically create as many KSEs >as defined by kern.threads.virtual_cpus. Perhaps we'll >add an environment variable to do this. > > It would probably be useful if the default for kern.threads.virtual_cpus took into account machdep.hlt_logical_cpus setting. (halving the default value if hlt_logical_cpus == 1, but as you say, it's really an optimization) And yes, my SMP box has machdep.cpu_idle_hlt: 0 although it sucks up about 100W more power that way and is about 20'F hotter in the chassis than with the idle_hlt. >Perhaps we also need a better method of auto-tuning the >number of KSEs. If KSEs are not utilizing much of their >quantum and there is a lot of idling and waking of them, >then we're better off with less of them. > > > I like the thread development a lot, using threads on FreeBSD was a futile thing only a short time ago, now it actually makes a lot of things easier to develop leading to more efficient applications. Pete From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 11:18:30 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 5E40337B407 for ; Mon, 7 Jul 2003 11:18:30 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCD3B43FA3 for ; Mon, 7 Jul 2003 11:18:29 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 22812 invoked from network); 7 Jul 2003 18:18:29 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 7 Jul 2003 18:18:29 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h67IIQGI093649 for ; Mon, 7 Jul 2003 14:18:27 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 07 Jul 2003 14:18:40 -0400 (EDT) From: John Baldwin To: threads@FreeBSD.org Subject: libc_r silliness 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, 07 Jul 2003 18:18:30 -0000 Just wondering why the PTHREAD_{MIN,MAX}_PRIORITY macros referenced in the pthread_{get,set}schedparam() man pages are not available to applications but are hidden in pthread_private.h. It would seem that these values should be exported in pthread.h. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 11:42: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 3234637B401 for ; Mon, 7 Jul 2003 11:42:12 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCF943F75 for ; Mon, 7 Jul 2003 11:42:11 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h67IgAAI005352; Mon, 7 Jul 2003 14:42:10 -0400 (EDT) Date: Mon, 7 Jul 2003 14:42:10 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <3F0994CB.6070403@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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: Mon, 07 Jul 2003 18:42:12 -0000 On Mon, 7 Jul 2003, Petri Helenius wrote: > Daniel Eischen wrote: > > >Mutexes are implemented using direct handoff (I think that's the > >term). Once a mutex is released, it is given to the next thread > >that is waiting on it and that thread is then marked runnable. > >Idle KSEs are suppose to be woken whenever there are runnable > >threads. > > > > > So when the main thread unlocks the mutex there are two runnable threads, > which one keeps running? The current thread. As I said before, if there are idle KSEs, then one is woken to run the newly runnable thread. > > >For now, just see if things work better with 1 CPU defined. > >If not, then all this talk about multiple KSEs isn't your > >problem; it is something else. > > > > > It definetly runs a lot better, however not as good as I would expect if > the running thread would be switched to the higher scheduling priority > thread immediately on the mutex release. Should that happen or does > it wait until the other thread hits a blocking condition ? It waits until either you hit a blocking condition or the quantum expires. The library is not (yet) smart enough to switch out the current thread after the unlock if the new owner has a higher priority. We could do that, but if there are other KSEs that can run the new thread, then they should get it. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 12:02:33 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 EF33C37B401; Mon, 7 Jul 2003 12:02:33 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51F1143FBF; Mon, 7 Jul 2003 12:02:33 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h67J2WAI008512; Mon, 7 Jul 2003 15:02:32 -0400 (EDT) Date: Mon, 7 Jul 2003 15:02:32 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: libc_r silliness 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: Mon, 07 Jul 2003 19:02:34 -0000 On Mon, 7 Jul 2003, John Baldwin wrote: > Just wondering why the PTHREAD_{MIN,MAX}_PRIORITY macros referenced in > the pthread_{get,set}schedparam() man pages are not available to > applications but are hidden in pthread_private.h. It would seem that > these values should be exported in pthread.h. Because they are not defined by the POSIX spec. According to POSIX you should use: sched_get_priority_max(), sched_get_priority_min() but it is confusing because these are specified for the process scheduling. The values returned by these system calls, do not necessarily correspond to the values used by our thread libraries (in fact, they don't). I believe somewhere in the old spec, there were supposed to be at least 31 or 32 priorities (I can't seem to find that mentioned in the new spec). Our thread libraries, at least libc_r and libpthread, use priorities 0 .. 31. I don't really know how to handle this. We can wrap sched_get_priority_{min,max}(), but how do we know whether the application wants process priorities or thread priorities? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 12:33:51 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 99BA937B401 for ; Mon, 7 Jul 2003 12:33:51 -0700 (PDT) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 831C443F93 for ; Mon, 7 Jul 2003 12:33:50 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5311 invoked from network); 7 Jul 2003 19:33:49 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 7 Jul 2003 19:33:49 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h67JXlGI093829; Mon, 7 Jul 2003 15:33:48 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 07 Jul 2003 15:34:02 -0400 (EDT) From: John Baldwin To: deischen@freebsd.org cc: threads@freebsd.org Subject: Re: libc_r silliness 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, 07 Jul 2003 19:33:51 -0000 On 07-Jul-2003 Daniel Eischen wrote: > On Mon, 7 Jul 2003, John Baldwin wrote: > >> Just wondering why the PTHREAD_{MIN,MAX}_PRIORITY macros referenced in >> the pthread_{get,set}schedparam() man pages are not available to >> applications but are hidden in pthread_private.h. It would seem that >> these values should be exported in pthread.h. > > Because they are not defined by the POSIX spec. According > to POSIX you should use: > > sched_get_priority_max(), sched_get_priority_min() > > but it is confusing because these are specified for the process > scheduling. The values returned by these system calls, do not > necessarily correspond to the values used by our thread libraries > (in fact, they don't). They do if you use SCHED_RR (which is the default policy) or SCHED_FIFO. SCHED_OTHER uses -20 to 20 (nice values). > I believe somewhere in the old spec, there were supposed to be > at least 31 or 32 priorities (I can't seem to find that mentioned > in the new spec). Our thread libraries, at least libc_r and > libpthread, use priorities 0 .. 31. > > I don't really know how to handle this. We can wrap > sched_get_priority_{min,max}(), but how do we know whether > the application wants process priorities or thread > priorities? Ugh. Perhaps the manpage should at least be updated to not reference the macros. What does POSIX say about the confusion between sched_get_priority_{min,max}? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 12:49:36 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 0700537B401; Mon, 7 Jul 2003 12:49:36 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 519AD43FBF; Mon, 7 Jul 2003 12:49:35 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h67JnYAI016268; Mon, 7 Jul 2003 15:49:34 -0400 (EDT) Date: Mon, 7 Jul 2003 15:49:34 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org Subject: Re: libc_r silliness 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: Mon, 07 Jul 2003 19:49:36 -0000 On Mon, 7 Jul 2003, John Baldwin wrote: > > On 07-Jul-2003 Daniel Eischen wrote: > > On Mon, 7 Jul 2003, John Baldwin wrote: > > > >> Just wondering why the PTHREAD_{MIN,MAX}_PRIORITY macros referenced in > >> the pthread_{get,set}schedparam() man pages are not available to > >> applications but are hidden in pthread_private.h. It would seem that > >> these values should be exported in pthread.h. > > > > Because they are not defined by the POSIX spec. According > > to POSIX you should use: > > > > sched_get_priority_max(), sched_get_priority_min() > > > > but it is confusing because these are specified for the process > > scheduling. The values returned by these system calls, do not > > necessarily correspond to the values used by our thread libraries > > (in fact, they don't). > > They do if you use SCHED_RR (which is the default policy) or SCHED_FIFO. > SCHED_OTHER uses -20 to 20 (nice values). And SCHED_OTHER is where the confusion lies. In our thread libraries (except libthr), SCHED_OTHER is treated the same as SCHED_RR (priorites 0 .. 31). This no matchy kernel. If you try to use those values in pthread_attr_setschedparam() or pthread_setschedparam(), you would get EINVAL for values less than 0. > > I believe somewhere in the old spec, there were supposed to be > > at least 31 or 32 priorities (I can't seem to find that mentioned > > in the new spec). Our thread libraries, at least libc_r and > > libpthread, use priorities 0 .. 31. > > > > I don't really know how to handle this. We can wrap > > sched_get_priority_{min,max}(), but how do we know whether > > the application wants process priorities or thread > > priorities? > > Ugh. Perhaps the manpage should at least be updated to not > reference the macros. What does POSIX say about the confusion > between sched_get_priority_{min,max}? Sure, update the man pages if you want ;-) I have not found anything yet regarding sched_get_priority_{min,max} confusion in the POSIX spec... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 14:37:37 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 122D737B401; Mon, 7 Jul 2003 14:37:37 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8294843F3F; Mon, 7 Jul 2003 14:37:35 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h67LbWsL013804; Tue, 8 Jul 2003 00:37:34 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <010501c344cf$f66be110$812a40c1@PETEX31> From: "Petri Helenius" To: References: Date: Tue, 8 Jul 2003 00:37:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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, 07 Jul 2003 21:37:37 -0000 > > So when the main thread unlocks the mutex there are two runnable threads, > > which one keeps running? > > The current thread. As I said before, if there are idle KSEs, then > one is woken to run the newly runnable thread. > Although I cannot prove this doesnŽt happen, I think the other thread does not get scheduled until a few moments later because when I get the scenario where thread1 has the mutex, thread2 is waiting on it, thread1 goes to cpu-bound tasks without holding the mutex, thread2 is not woken up, at least not immediately. Is there a delay for waking up the KSE? Obviously if neccessary I can write a simple test program to spit out timestamps. > > It waits until either you hit a blocking condition or the > quantum expires. The library is not (yet) smart enough > to switch out the current thread after the unlock if the > new owner has a higher priority. We could do that, but > if there are other KSEs that can run the new thread, then > they should get it. > IŽll test more soon and see if I can identify a reproducable issue. Pete From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 15:53:37 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 F14D637B404 for ; Mon, 7 Jul 2003 15:53:36 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01C1243FAF for ; Mon, 7 Jul 2003 15:53:36 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h67MrYAI017592; Mon, 7 Jul 2003 18:53:35 -0400 (EDT) Date: Mon, 7 Jul 2003 18:53:34 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <010501c344cf$f66be110$812a40c1@PETEX31> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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: Mon, 07 Jul 2003 22:53:37 -0000 On Tue, 8 Jul 2003, Petri Helenius wrote: > > > So when the main thread unlocks the mutex there are two runnable thre= ads, > > > which one keeps running? > > > > The current thread. As I said before, if there are idle KSEs, then > > one is woken to run the newly runnable thread. > > > Although I cannot prove this doesn=B4t happen, I think the other > thread does not get scheduled until a few moments later because > when I get the scenario where thread1 has the mutex, thread2 > is waiting on it, thread1 goes to cpu-bound tasks without > holding the mutex, thread2 is not woken up, at least not immediately. The KSE is woken immediately, but you are at the whimsy of the kernel scheduler. Depending on what else is running, the woken KSE may not run right away. You can see the wakeups using ktrace... --=20 Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 19:51:03 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 D74A037B401 for ; Mon, 7 Jul 2003 19:51:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E87343FCB for ; Mon, 7 Jul 2003 19:51:03 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h682p0Up087595 for ; Mon, 7 Jul 2003 19:51:02 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <008201c344fc$392c0760$f001a8c0@davidw2k> From: "David Xu" To: Date: Tue, 8 Jul 2003 10:54:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: ttyname_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 02:51:04 -0000 I found our ttyname_r has different return type than POSIX: http://www.opengroup.org/onlinepubs/007904975/functions/ttyname.html and POSIX says: If successful, the ttyname_r() function shall return zero. Otherwise, an error number shall be returned to indicate the error. libc implements it as following format: char * ttyname_r(int fd, char *buf, size_t len); and when success, it returns non-NULL pointer, it almost has opposite meaning with POSIX. This causes some pthread tests failed here. David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 22:42:20 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 60D5937B404; Mon, 7 Jul 2003 22:42:20 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B931443FAF; Mon, 7 Jul 2003 22:42:19 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h685gJAI017646; Tue, 8 Jul 2003 01:42:19 -0400 (EDT) Date: Tue, 8 Jul 2003 01:42:18 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <008201c344fc$392c0760$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: ttyname_r 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: Tue, 08 Jul 2003 05:42:20 -0000 On Tue, 8 Jul 2003, David Xu wrote: > I found our ttyname_r has different return type than POSIX: > http://www.opengroup.org/onlinepubs/007904975/functions/ttyname.html > and POSIX says: > If successful, the ttyname_r() function shall return zero. > Otherwise, an error number shall be returned to indicate the error. > > libc implements it as following format: > char * ttyname_r(int fd, char *buf, size_t len); > and when success, it returns non-NULL pointer, it almost has opposite > meaning with POSIX. > This causes some pthread tests failed here. I seem to remember this issue coming up before, but I don't recall what the outcome was. FWIW, Solaris defines ttyname_r both ways (according to to ttyname_r(3C)): #ifdef _POSIX_PTHREAD_SEMANTICS int ttyname_r(int fildes, char *name, size_t namesize); #else char *ttyname_r(int fildes, char *name, int namelen); #endif I'd support changing it, but I don't know whether we'd need a library version bump to do that. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 00:35:05 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 258FA37B401; Tue, 8 Jul 2003 00:35:05 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF35C43FBF; Tue, 8 Jul 2003 00:35:03 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h687Z1sL017963; Tue, 8 Jul 2003 10:35:02 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F0A7425.9080300@he.iki.fi> Date: Tue, 08 Jul 2003 10:35:01 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: deischen@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority with libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 07:35:05 -0000 Daniel Eischen wrote: >The current thread. As I said before, if there are idle KSEs, then >one is woken to run the newly runnable thread. > I'm seeing about 200 microsecond latency when scheduling the thread on the other KSE. Which translates to maximum of 2500 "spins" of the contested loop a second. Same code runs about 500000 spins a second when no locking is involved. This is on othervise idle Dual 2.4 Xeon. If the mutex performance sounds about right, I need to redesign my locking to go from one contested lock to many uncontested ones, which sounds a good idea anyway. >It waits until either you hit a blocking condition or the >quantum expires. The library is not (yet) smart enough >to switch out the current thread after the unlock if the >new owner has a higher priority. We could do that, but >if there are other KSEs that can run the new thread, then >they should get it. > > > But the library is smart enough to extend the quantum on a higher priority thread if SCHED_RR is in effect? I'm seeing multiples of 20ms being allocated with two runnable threads of priorities 15 and 20 competing for the CPU. Pete From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 03:37:08 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 1754F37B401; Tue, 8 Jul 2003 03:37:08 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7106343F75; Tue, 8 Jul 2003 03:37:07 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc01p.dialup.mindspring.com ([209.86.0.57] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19ZpqM-0003jZ-00; Tue, 08 Jul 2003 03:37:07 -0700 Message-ID: <3F0A9E8E.99CA9BD@mindspring.com> Date: Tue, 08 Jul 2003 03:35:58 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: deischen@FreeBSD.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e8e3623f1f952ee9c09b7488d51cbdd7a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: threads@FreeBSD.org cc: John Baldwin Subject: Re: libc_r silliness X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 10:37:08 -0000 Daniel Eischen wrote: > On Mon, 7 Jul 2003, John Baldwin wrote: > > > I don't really know how to handle this. We can wrap > > > sched_get_priority_{min,max}(), but how do we know whether > > > the application wants process priorities or thread > > > priorities? > > > > Ugh. Perhaps the manpage should at least be updated to not > > reference the macros. What does POSIX say about the confusion > > between sched_get_priority_{min,max}? > > Sure, update the man pages if you want ;-) > > I have not found anything yet regarding sched_get_priority_{min,max} > confusion in the POSIX spec... http://www.opengroup.org/onlinepubs/007904975/functions/sched_get_priority_max.html The functions take a policy parameter; they are supposed to return "appropriate" values, which I took to mean "appropriate to the policy parameter supplied at the time they were called": int sched_get_priority_max(int policy); int sched_get_priority_min(int policy); The sched_get_priority_max() and sched_get_priority_min() functions shall return the appropriate maximum or minimum, respectively, for the scheduling policy specified by policy. -- Terry From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 06:18:30 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 1B11937B401 for ; Tue, 8 Jul 2003 06:18:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7714143FDF for ; Tue, 8 Jul 2003 06:18:29 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h68DISAI022178; Tue, 8 Jul 2003 09:18:28 -0400 (EDT) Date: Tue, 8 Jul 2003 09:18:28 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <3F0A7425.9080300@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority with libkse 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: Tue, 08 Jul 2003 13:18:30 -0000 On Tue, 8 Jul 2003, Petri Helenius wrote: > Daniel Eischen wrote: > > >The current thread. As I said before, if there are idle KSEs, then > >one is woken to run the newly runnable thread. > > > I'm seeing about 200 microsecond latency when scheduling the thread on > the other > KSE. Which translates to maximum of 2500 "spins" of the contested loop > a second. That's the time it takes for the KSE to be woken up in the kernel and scheduled. > Same code runs about 500000 spins a second when no locking is involved. > > This is on othervise idle Dual 2.4 Xeon. > > If the mutex performance sounds about right, I need to redesign my > locking to > go from one contested lock to many uncontested ones, which sounds a good > idea > anyway. > > >It waits until either you hit a blocking condition or the > >quantum expires. The library is not (yet) smart enough > >to switch out the current thread after the unlock if the > >new owner has a higher priority. We could do that, but > >if there are other KSEs that can run the new thread, then > >they should get it. > > > > > > > But the library is smart enough to extend the quantum on a higher > priority thread if SCHED_RR is in effect? I'm seeing multiples > of 20ms being allocated with two runnable threads of priorities > 15 and 20 competing for the CPU. A higher priority thread will always be run over a low priority thread, regardless of quantum. So yes, quantum is continually extended as long as the thread remains the highest priority thread and continues to be runnable. The library currently uses 20msec for the round-robin interval. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 06:24:21 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 589E137B401 for ; Tue, 8 Jul 2003 06:24:21 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18D5743FA3 for ; Tue, 8 Jul 2003 06:24:20 -0700 (PDT) (envelope-from john@baldwin.cx) Received: (qmail 3617 invoked from network); 8 Jul 2003 13:24:18 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 8 Jul 2003 13:24:18 -0000 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h68DOGGI095882; Tue, 8 Jul 2003 09:24:16 -0400 (EDT) (envelope-from john@baldwin.cx) Received: from zion.baldwin.cx (localhost [127.0.0.1]) by zion.baldwin.cx (8.12.9/8.12.9) with ESMTP id h68DOGPg038159; Tue, 8 Jul 2003 09:24:16 -0400 (EDT) (envelope-from john@zion.baldwin.cx) Received: from localhost (localhost [[UNIX: localhost]]) by zion.baldwin.cx (8.12.9/8.12.9/Submit) id h68DOFiS038158; Tue, 8 Jul 2003 09:24:15 -0400 (EDT) From: John Baldwin To: Terry Lambert , deischen@FreeBSD.org Date: Tue, 8 Jul 2003 09:23:20 -0400 User-Agent: KMail/1.5 References: <3F0A9E8E.99CA9BD@mindspring.com> In-Reply-To: <3F0A9E8E.99CA9BD@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307080923.20011.jhb@FreeBSD.org> cc: threads@FreeBSD.org Subject: Re: libc_r silliness X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 13:24:21 -0000 On Tuesday 08 July 2003 06:35 am, Terry Lambert wrote: > Daniel Eischen wrote: > > On Mon, 7 Jul 2003, John Baldwin wrote: > > > > I don't really know how to handle this. We can wrap > > > > sched_get_priority_{min,max}(), but how do we know whether > > > > the application wants process priorities or thread > > > > priorities? > > > > > > Ugh. Perhaps the manpage should at least be updated to not > > > reference the macros. What does POSIX say about the confusion > > > between sched_get_priority_{min,max}? > > > > Sure, update the man pages if you want ;-) > > > > I have not found anything yet regarding sched_get_priority_{min,max} > > confusion in the POSIX spec... > > http://www.opengroup.org/onlinepubs/007904975/functions/sched_get_priority_ >max.html > > The functions take a policy parameter; they are supposed to > return "appropriate" values, which I took to mean "appropriate > to the policy parameter supplied at the time they were called": > > int sched_get_priority_max(int policy); > int sched_get_priority_min(int policy); > > The sched_get_priority_max() and sched_get_priority_min() > functions shall return the appropriate maximum or minimum, > respectively, for the scheduling policy specified by policy. Yes, but in a multithreaded program when I call sched_get_priority_max(SCHED_RR), does that tell me the maximum process SCHED_RR priority for use with sched_setschedparam() or does it tell me the maximum thread SCHED_RR priority for use with pthread_setschedparam()? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 15:01:37 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 6953137B401; Tue, 8 Jul 2003 15:01:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E867143F75; Tue, 8 Jul 2003 15:01:34 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h68M1WUp063358; Tue, 8 Jul 2003 15:01:33 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <001201c3459c$f0f66480$0701a8c0@tiger> From: "David Xu" To: "John Baldwin" , "Terry Lambert" , References: <3F0A9E8E.99CA9BD@mindspring.com> <200307080923.20011.jhb@FreeBSD.org> Date: Wed, 9 Jul 2003 06:04:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 cc: threads@freebsd.org Subject: Re: libc_r silliness X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 08 Jul 2003 22:01:37 -0000 ----- Original Message -----=20 From: "John Baldwin" To: "Terry Lambert" ; Cc: Sent: Tuesday, July 08, 2003 9:23 PM Subject: Re: libc_r silliness > On Tuesday 08 July 2003 06:35 am, Terry Lambert wrote: > > Daniel Eischen wrote: > > > On Mon, 7 Jul 2003, John Baldwin wrote: > > > > > I don't really know how to handle this. We can wrap > > > > > sched_get_priority_{min,max}(), but how do we know whether > > > > > the application wants process priorities or thread > > > > > priorities? > > > > > > > > Ugh. Perhaps the manpage should at least be updated to not > > > > reference the macros. What does POSIX say about the confusion > > > > between sched_get_priority_{min,max}? > > > > > > Sure, update the man pages if you want ;-) > > > > > > I have not found anything yet regarding = sched_get_priority_{min,max} > > > confusion in the POSIX spec... > > > > = http://www.opengroup.org/onlinepubs/007904975/functions/sched_get_priorit= y_ > >max.html > > > > The functions take a policy parameter; they are supposed to > > return "appropriate" values, which I took to mean "appropriate > > to the policy parameter supplied at the time they were called": > > > > int sched_get_priority_max(int policy); > > int sched_get_priority_min(int policy); > > > > The sched_get_priority_max() and sched_get_priority_min() > > functions shall return the appropriate maximum or minimum, > > respectively, for the scheduling policy specified by policy. >=20 > Yes, but in a multithreaded program when I call=20 > sched_get_priority_max(SCHED_RR), does that tell me the maximum = process=20 > SCHED_RR priority for use with sched_setschedparam() or does it tell = me the=20 > maximum thread SCHED_RR priority for use with pthread_setschedparam()? >=20 See page: http://www.opengroup.org/onlinepubs/007904975/basedefs/sched.h.html They are marked with 'TPS' code, so they are applied to thread = scheduling. Otherwise, they should be marked with 'PS' code. This is the code page: http://www.opengroup.org/onlinepubs/007904975/help/codes.html > --=20 >=20 > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > _______________________________________________ > 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 David Xu From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 15:12: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 A9CD337B401; Tue, 8 Jul 2003 15:12:57 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7D5243F3F; Tue, 8 Jul 2003 15:12:53 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <2003070822125301300iqh2oe>; Tue, 8 Jul 2003 22:12:53 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA24144; Tue, 8 Jul 2003 15:12:51 -0700 (PDT) Date: Tue, 8 Jul 2003 15:12:49 -0700 (PDT) From: Julian Elischer To: deischen@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority with libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 22:12:58 -0000 On Tue, 8 Jul 2003, Daniel Eischen wrote: > On Tue, 8 Jul 2003, Petri Helenius wrote: > > Daniel Eischen wrote: > > > > >The current thread. As I said before, if there are idle KSEs, then > > >one is woken to run the newly runnable thread. > > > > > I'm seeing about 200 microsecond latency when scheduling the thread on > > the other > > KSE. Which translates to maximum of 2500 "spins" of the contested loop > > a second. > > That's the time it takes for the KSE to be woken up in the > kernel and scheduled. It's the time it takes for the idle thread in the other processor to notice that there is work to do and to fetch it.. I wonder if we are doing an IPI in this case..? maybe we should.. I'll go look at the code to see why it takes so long. (you might also see what happens if you set machdep.cpu_idle_hlt to be 0) > > > Same code runs about 500000 spins a second when no locking is involved. > > > > This is on othervise idle Dual 2.4 Xeon. > > > > If the mutex performance sounds about right, I need to redesign my > > locking to > > go from one contested lock to many uncontested ones, which sounds a good > > idea > > anyway. > > > > > >It waits until either you hit a blocking condition or the > > >quantum expires. The library is not (yet) smart enough > > >to switch out the current thread after the unlock if the > > >new owner has a higher priority. We could do that, but > > >if there are other KSEs that can run the new thread, then > > >they should get it. > > > > > > > > > > > But the library is smart enough to extend the quantum on a higher > > priority thread if SCHED_RR is in effect? I'm seeing multiples > > of 20ms being allocated with two runnable threads of priorities > > 15 and 20 competing for the CPU. > > A higher priority thread will always be run over a low > priority thread, regardless of quantum. So yes, quantum > is continually extended as long as the thread remains > the highest priority thread and continues to be runnable. > The library currently uses 20msec for the round-robin > interval. > > -- > Dan Eischen > > _______________________________________________ > 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 Tue Jul 8 15:21:50 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 3A80037B401 for ; Tue, 8 Jul 2003 15:21:50 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A0B743F93 for ; Tue, 8 Jul 2003 15:21:49 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 8260 invoked from network); 8 Jul 2003 22:21:48 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 8 Jul 2003 22:21:48 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h68MLhGI096996; Tue, 8 Jul 2003 18:21:44 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <001201c3459c$f0f66480$0701a8c0@tiger> Date: Tue, 08 Jul 2003 18:21:58 -0400 (EDT) From: John Baldwin To: David Xu cc: deischen@freebsd.org cc: threads@freebsd.org Subject: Re: libc_r silliness X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 22:21:50 -0000 On 08-Jul-2003 David Xu wrote: > > ----- Original Message ----- > From: "John Baldwin" > To: "Terry Lambert" ; > Cc: > Sent: Tuesday, July 08, 2003 9:23 PM > Subject: Re: libc_r silliness > > >> On Tuesday 08 July 2003 06:35 am, Terry Lambert wrote: >> > Daniel Eischen wrote: >> > > On Mon, 7 Jul 2003, John Baldwin wrote: >> > > > > I don't really know how to handle this. We can wrap >> > > > > sched_get_priority_{min,max}(), but how do we know whether >> > > > > the application wants process priorities or thread >> > > > > priorities? >> > > > >> > > > Ugh. Perhaps the manpage should at least be updated to not >> > > > reference the macros. What does POSIX say about the confusion >> > > > between sched_get_priority_{min,max}? >> > > >> > > Sure, update the man pages if you want ;-) >> > > >> > > I have not found anything yet regarding sched_get_priority_{min,max} >> > > confusion in the POSIX spec... >> > >> > http://www.opengroup.org/onlinepubs/007904975/functions/sched_get_priority_ >> >max.html >> > >> > The functions take a policy parameter; they are supposed to >> > return "appropriate" values, which I took to mean "appropriate >> > to the policy parameter supplied at the time they were called": >> > >> > int sched_get_priority_max(int policy); >> > int sched_get_priority_min(int policy); >> > >> > The sched_get_priority_max() and sched_get_priority_min() >> > functions shall return the appropriate maximum or minimum, >> > respectively, for the scheduling policy specified by policy. >> >> Yes, but in a multithreaded program when I call >> sched_get_priority_max(SCHED_RR), does that tell me the maximum process >> SCHED_RR priority for use with sched_setschedparam() or does it tell me the >> maximum thread SCHED_RR priority for use with pthread_setschedparam()? >> > See page: > http://www.opengroup.org/onlinepubs/007904975/basedefs/sched.h.html > They are marked with 'TPS' code, so they are applied to thread scheduling. > Otherwise, they should be marked with 'PS' code. > This is the code page: > http://www.opengroup.org/onlinepubs/007904975/help/codes.html Hmm, then why do we have these in the kernel? Shouldn't these be implemented in each thread library instead? Was this another one of the hacks to make LinuxThreads work? It sounds like each threading library should provide these functions and the kernel has no business supplying them. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 16:38: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 4843237B401; Tue, 8 Jul 2003 16:38:41 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F38D43F93; Tue, 8 Jul 2003 16:38:40 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h68NcbAI005883; Tue, 8 Jul 2003 19:38:39 -0400 (EDT) Date: Tue, 8 Jul 2003 19:38:37 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <001201c3459c$f0f66480$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: John Baldwin Subject: Re: libc_r silliness 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: Tue, 08 Jul 2003 23:38:41 -0000 On Wed, 9 Jul 2003, David Xu wrote: > > From: "John Baldwin" > > > On Tuesday 08 July 2003 06:35 am, Terry Lambert wrote: > > > Daniel Eischen wrote: > > > > I have not found anything yet regarding sched_get_priority_{min,max} > > > > confusion in the POSIX spec... > > > > > > http://www.opengroup.org/onlinepubs/007904975/functions/sched_get_priority_ > > >max.html > > > > > > The functions take a policy parameter; they are supposed to > > > return "appropriate" values, which I took to mean "appropriate > > > to the policy parameter supplied at the time they were called": > > > > > > int sched_get_priority_max(int policy); > > > int sched_get_priority_min(int policy); > > > > > > The sched_get_priority_max() and sched_get_priority_min() > > > functions shall return the appropriate maximum or minimum, > > > respectively, for the scheduling policy specified by policy. > > > > Yes, but in a multithreaded program when I call > > sched_get_priority_max(SCHED_RR), does that tell me the maximum process > > SCHED_RR priority for use with sched_setschedparam() or does it tell me the > > maximum thread SCHED_RR priority for use with pthread_setschedparam()? > > > See page: > http://www.opengroup.org/onlinepubs/007904975/basedefs/sched.h.html > They are marked with 'TPS' code, so they are applied to thread scheduling. > Otherwise, they should be marked with 'PS' code. Actually, is marked PS, not TPS, and the text of the page talks about "process": Each process is controlled by an associated scheduling policy and priority. Associated with each policy is a priority range. Each policy definition specifies the minimum priority range for that policy. The priority ranges for each policy may overlap the priority ranges of other policies. Regardless, we have kernel scheduling parameters _and_ thread scheduling parameters. From my interpretation, these interfaces refer to the process scheduling, not thread scheduling. This is a good link too: http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_08.html#tag_02_08_04_01 Each process shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the sched_setscheduler() or sched_setparam() functions. Each thread shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the pthread_setschedparam() function. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 16:41:35 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 D4D9737B401 for ; Tue, 8 Jul 2003 16:41:35 -0700 (PDT) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2C7C43FCB for ; Tue, 8 Jul 2003 16:41:34 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4719 invoked from network); 8 Jul 2003 23:41:34 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 8 Jul 2003 23:41:34 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h68NfVGI097178; Tue, 8 Jul 2003 19:41:32 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 08 Jul 2003 19:41:45 -0400 (EDT) From: John Baldwin To: deischen@freebsd.org cc: threads@freebsd.org cc: David Xu Subject: Re: libc_r silliness X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 23:41:36 -0000 On 08-Jul-2003 Daniel Eischen wrote: > On Wed, 9 Jul 2003, David Xu wrote: >> >> From: "John Baldwin" >> >> > On Tuesday 08 July 2003 06:35 am, Terry Lambert wrote: >> > > Daniel Eischen wrote: >> > > > I have not found anything yet regarding sched_get_priority_{min,max} >> > > > confusion in the POSIX spec... >> > > >> > > http://www.opengroup.org/onlinepubs/007904975/functions/sched_get_priority_ >> > >max.html >> > > >> > > The functions take a policy parameter; they are supposed to >> > > return "appropriate" values, which I took to mean "appropriate >> > > to the policy parameter supplied at the time they were called": >> > > >> > > int sched_get_priority_max(int policy); >> > > int sched_get_priority_min(int policy); >> > > >> > > The sched_get_priority_max() and sched_get_priority_min() >> > > functions shall return the appropriate maximum or minimum, >> > > respectively, for the scheduling policy specified by policy. >> > >> > Yes, but in a multithreaded program when I call >> > sched_get_priority_max(SCHED_RR), does that tell me the maximum process >> > SCHED_RR priority for use with sched_setschedparam() or does it tell me the >> > maximum thread SCHED_RR priority for use with pthread_setschedparam()? >> > >> See page: >> http://www.opengroup.org/onlinepubs/007904975/basedefs/sched.h.html >> They are marked with 'TPS' code, so they are applied to thread scheduling. >> Otherwise, they should be marked with 'PS' code. > > Actually, is marked PS, not TPS, and the text of > the page talks about "process": > > Each process is controlled by an associated scheduling policy > and priority. Associated with each policy is a priority range. > Each policy definition specifies the minimum priority range for > that policy. The priority ranges for each policy may overlap > the priority ranges of other policies. > > Regardless, we have kernel scheduling parameters _and_ thread > scheduling parameters. From my interpretation, these interfaces > refer to the process scheduling, not thread scheduling. > This is a good link too: > > http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_08.html#tag_02_08_04_01 > > Each process shall be controlled by an associated scheduling policy > and priority. These parameters may be specified by explicit > application execution of the sched_setscheduler() or > sched_setparam() functions. > > Each thread shall be controlled by an associated scheduling policy > and priority. These parameters may be specified by explicit > application execution of the pthread_setschedparam() function. So is X/Open OSI whoever just assuming that the process and thread scheduling policies implement identical priority ranges? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 16:47:01 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 7DF3637B401; Tue, 8 Jul 2003 16:47:01 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC74E43F3F; Tue, 8 Jul 2003 16:47:00 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h68Nl0AI007658; Tue, 8 Jul 2003 19:47:00 -0400 (EDT) Date: Tue, 8 Jul 2003 19:47:00 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org cc: David Xu Subject: Re: libc_r silliness 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: Tue, 08 Jul 2003 23:47:01 -0000 On Tue, 8 Jul 2003, John Baldwin wrote: > > On 08-Jul-2003 Daniel Eischen wrote: > > Actually, is marked PS, not TPS, and the text of > > the page talks about "process": > > > > Each process is controlled by an associated scheduling policy > > and priority. Associated with each policy is a priority range. > > Each policy definition specifies the minimum priority range for > > that policy. The priority ranges for each policy may overlap > > the priority ranges of other policies. > > > > Regardless, we have kernel scheduling parameters _and_ thread > > scheduling parameters. From my interpretation, these interfaces > > refer to the process scheduling, not thread scheduling. > > This is a good link too: > > > > http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_08.html#tag_02_08_04_01 > > > > Each process shall be controlled by an associated scheduling policy > > and priority. These parameters may be specified by explicit > > application execution of the sched_setscheduler() or > > sched_setparam() functions. > > > > Each thread shall be controlled by an associated scheduling policy > > and priority. These parameters may be specified by explicit > > application execution of the pthread_setschedparam() function. > > So is X/Open OSI whoever just assuming that the process and thread > scheduling policies implement identical priority ranges? I dunno, but it seems that is the case. We could add pthread_get_priority_{min,max}_np(int policy) as non-portable functions. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 17:01:14 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 BBF2E37B404 for ; Tue, 8 Jul 2003 17:01:14 -0700 (PDT) Received: from mail.speakeasy.net (mail8.speakeasy.net [216.254.0.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81FA243FB1 for ; Tue, 8 Jul 2003 17:01:13 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25361 invoked from network); 9 Jul 2003 00:01:12 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 9 Jul 2003 00:01:12 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h6901AGI097240; Tue, 8 Jul 2003 20:01:11 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 08 Jul 2003 20:01:24 -0400 (EDT) From: John Baldwin To: deischen@FreeBSD.org cc: David Xu cc: threads@FreeBSD.org Subject: Re: libc_r silliness 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: Wed, 09 Jul 2003 00:01:15 -0000 On 08-Jul-2003 Daniel Eischen wrote: > On Tue, 8 Jul 2003, John Baldwin wrote: >> >> On 08-Jul-2003 Daniel Eischen wrote: >> > Actually, is marked PS, not TPS, and the text of >> > the page talks about "process": >> > >> > Each process is controlled by an associated scheduling policy >> > and priority. Associated with each policy is a priority range. >> > Each policy definition specifies the minimum priority range for >> > that policy. The priority ranges for each policy may overlap >> > the priority ranges of other policies. >> > >> > Regardless, we have kernel scheduling parameters _and_ thread >> > scheduling parameters. From my interpretation, these interfaces >> > refer to the process scheduling, not thread scheduling. >> > This is a good link too: >> > >> > http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_08.html#tag_02_08_04_01 >> > >> > Each process shall be controlled by an associated scheduling policy >> > and priority. These parameters may be specified by explicit >> > application execution of the sched_setscheduler() or >> > sched_setparam() functions. >> > >> > Each thread shall be controlled by an associated scheduling policy >> > and priority. These parameters may be specified by explicit >> > application execution of the pthread_setschedparam() function. >> >> So is X/Open OSI whoever just assuming that the process and thread >> scheduling policies implement identical priority ranges? > > I dunno, but it seems that is the case. > > We could add pthread_get_priority_{min,max}_np(int policy) as > non-portable functions. We could also just force all the thread libraries and kernel to use the same priority ranges. Another possibility is to have each thread library provide their own sched_get_{min,max} and wrap the sched_{get,set}schedparam() syscalls to massage the thread priority values into their corresponding process priority values to simulate a single priority space for each policy. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 17:12:18 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 2F70737B401; Tue, 8 Jul 2003 17:12:18 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82DBD43F93; Tue, 8 Jul 2003 17:12:17 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h690CGAI011617; Tue, 8 Jul 2003 20:12:16 -0400 (EDT) Date: Tue, 8 Jul 2003 20:12:16 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: threads@FreeBSD.org Subject: Re: libc_r silliness 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: Wed, 09 Jul 2003 00:12:18 -0000 On Tue, 8 Jul 2003, John Baldwin wrote: > On 08-Jul-2003 Daniel Eischen wrote: > > On Tue, 8 Jul 2003, John Baldwin wrote: > >> So is X/Open OSI whoever just assuming that the process and thread > >> scheduling policies implement identical priority ranges? > > > > I dunno, but it seems that is the case. > > > > We could add pthread_get_priority_{min,max}_np(int policy) as > > non-portable functions. > > We could also just force all the thread libraries and kernel to > use the same priority ranges. I don't want to have SCHED_OTHER with -20 .. 20 in libpthread. > Another possibility is to have > each thread library provide their own sched_get_{min,max} and > wrap the sched_{get,set}schedparam() syscalls to massage the > thread priority values into their corresponding process priority > values to simulate a single priority space for each policy. I like this better than the other option, but how do you know that when the application calls sched_setschedparam() with a priority of 10, that it really came from sched_get_priority_min() + 10 (meaning -10) or whether it was hardcoded to 10 and really wants 10. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 17:28:20 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 9DDE237B401 for ; Tue, 8 Jul 2003 17:28:20 -0700 (PDT) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED3AF43F3F for ; Tue, 8 Jul 2003 17:28:19 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1513 invoked from network); 9 Jul 2003 00:28:19 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 9 Jul 2003 00:28:19 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h690SEGI097286; Tue, 8 Jul 2003 20:28:15 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 08 Jul 2003 20:28:28 -0400 (EDT) From: John Baldwin To: Daniel Eischen cc: threads@FreeBSD.org cc: David Xu Subject: Re: libc_r silliness 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: Wed, 09 Jul 2003 00:28:20 -0000 On 09-Jul-2003 Daniel Eischen wrote: > On Tue, 8 Jul 2003, John Baldwin wrote: >> On 08-Jul-2003 Daniel Eischen wrote: >> > On Tue, 8 Jul 2003, John Baldwin wrote: >> >> So is X/Open OSI whoever just assuming that the process and thread >> >> scheduling policies implement identical priority ranges? >> > >> > I dunno, but it seems that is the case. >> > >> > We could add pthread_get_priority_{min,max}_np(int policy) as >> > non-portable functions. >> >> We could also just force all the thread libraries and kernel to >> use the same priority ranges. > > I don't want to have SCHED_OTHER with -20 .. 20 in libpthread. We could use 0..39 for process priorities and have the kernel do the right math to convert that to a nice value. The kernel process priorities don't _have_ to be nice values. >> Another possibility is to have >> each thread library provide their own sched_get_{min,max} and >> wrap the sched_{get,set}schedparam() syscalls to massage the >> thread priority values into their corresponding process priority >> values to simulate a single priority space for each policy. > > I like this better than the other option, but how do you > know that when the application calls sched_setschedparam() > with a priority of 10, that it really came from > sched_get_priority_min() + 10 (meaning -10) or whether it was > hardcoded to 10 and really wants 10. You aren't supposed to hard code 10, you're supposed to derive your value from the min() and max() functions as far as I can tell. :-P -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 17:29: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 EEF6737B401; Tue, 8 Jul 2003 17:29:11 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7322A43FB1; Tue, 8 Jul 2003 17:29:11 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h690T9Up078634; Tue, 8 Jul 2003 17:29:10 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <005101c345b1$8fdb7cc0$0701a8c0@tiger> From: "David Xu" To: , "John Baldwin" References: Date: Wed, 9 Jul 2003 08:32:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 cc: threads@freebsd.org Subject: Re: libc_r silliness X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 09 Jul 2003 00:29:12 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "John Baldwin" Cc: "David Xu" ; Sent: Wednesday, July 09, 2003 8:12 AM Subject: Re: libc_r silliness > On Tue, 8 Jul 2003, John Baldwin wrote: > > On 08-Jul-2003 Daniel Eischen wrote: > > > On Tue, 8 Jul 2003, John Baldwin wrote: > > >> So is X/Open OSI whoever just assuming that the process and = thread > > >> scheduling policies implement identical priority ranges? > > >=20 > > > I dunno, but it seems that is the case. > > >=20 > > > We could add pthread_get_priority_{min,max}_np(int policy) as > > > non-portable functions. > >=20 > > We could also just force all the thread libraries and kernel to > > use the same priority ranges. >=20 > I don't want to have SCHED_OTHER with -20 .. 20 in libpthread. >=20 > > Another possibility is to have > > each thread library provide their own sched_get_{min,max} and > > wrap the sched_{get,set}schedparam() syscalls to massage the > > thread priority values into their corresponding process priority > > values to simulate a single priority space for each policy. >=20 > I like this better than the other option, but how do you > know that when the application calls sched_setschedparam() > with a priority of 10, that it really came from > sched_get_priority_min() + 10 (meaning -10) or whether it was > hardcoded to 10 and really wants 10. >=20 >From a book "Programming for the real world POSIX.4", The author said about sched_get_priority_max/min: Notes: Since the range of scheduling priorities varies from system to system, applications should refrain from calling the POSIX.4 scheduling algorithms with straight priority numbers. Rather, a virtual priority range should be used; then it should be = shifted appropriately based on the values returned from = sched_get_priority_min and sched_get_priority_max. > --=20 > Dan Eischen >=20 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to = "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 18:06:23 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 17C0A37B43C; Tue, 8 Jul 2003 18:06:23 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59D9F43F3F; Tue, 8 Jul 2003 18:06:22 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h6916JAI020360; Tue, 8 Jul 2003 21:06:20 -0400 (EDT) Date: Tue, 8 Jul 2003 21:06:19 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org cc: David Xu Subject: Re: libc_r silliness 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: Wed, 09 Jul 2003 01:06:23 -0000 On Tue, 8 Jul 2003, John Baldwin wrote: > > On 09-Jul-2003 Daniel Eischen wrote: ^^ Is there a time lag somewhere :-) > > On Tue, 8 Jul 2003, John Baldwin wrote: > >> Another possibility is to have > >> each thread library provide their own sched_get_{min,max} and > >> wrap the sched_{get,set}schedparam() syscalls to massage the > >> thread priority values into their corresponding process priority > >> values to simulate a single priority space for each policy. > > > > I like this better than the other option, but how do you > > know that when the application calls sched_setschedparam() > > with a priority of 10, that it really came from > > sched_get_priority_min() + 10 (meaning -10) or whether it was > > hardcoded to 10 and really wants 10. > > You aren't supposed to hard code 10, you're supposed to derive > your value from the min() and max() functions as far as I can > tell. :-P Well, yup, that's what you're _suppose_ to do... I guess we can do this. To summarize: sched_get_schedparam(), sched_set_schedparam(), sched_get_priority_min(), sched_get_priority_max() will be provided by the thread libraries (unless kernel and thread priorities match for all scheduling protocols). The library functions sched_get_schedparam(), sched_get_priority_min(), and sched_get_priority_max() will call the respective system calls and convert kernel SCHED_OTHER priorities to thread SCHED_OTHER priorities before returning. The library function sched_set_schedparam() will convert thread SCHED_OTHER priorities to kernel SCHED_OTHER priorities before making the actual system call. If the thread priority ranges for SCHED_FIFO and SCHED_RR do not match the kernel priority ranges, the thread libraries will do similar conversions (they might just as well do the conversions even if they are the same). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 23:22:03 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 1BCCA37B401; Tue, 8 Jul 2003 23:22:03 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 700F343FBF; Tue, 8 Jul 2003 23:22:02 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldtos.dialup.mindspring.com ([209.86.247.28] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19a8L3-0000P0-00; Tue, 08 Jul 2003 23:22:01 -0700 Message-ID: <3F0BB44C.FB24CBE5@mindspring.com> Date: Tue, 08 Jul 2003 23:21:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin References: <3F0A9E8E.99CA9BD@mindspring.com> <200307080923.20011.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44ae6e18bab27483bff5267826351b4fd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: deischen@FreeBSD.org cc: threads@FreeBSD.org Subject: Re: libc_r silliness 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: Wed, 09 Jul 2003 06:22:03 -0000 John Baldwin wrote: > On Tuesday 08 July 2003 06:35 am, Terry Lambert wrote: > > > I have not found anything yet regarding sched_get_priority_{min,max} > > > confusion in the POSIX spec... > > > > http://www.opengroup.org/onlinepubs/007904975/functions/sched_get_priority_ > >max.html > > > > The functions take a policy parameter; they are supposed to > > return "appropriate" values, which I took to mean "appropriate > > to the policy parameter supplied at the time they were called": > > Yes, but in a multithreaded program when I call > sched_get_priority_max(SCHED_RR), does that tell me the maximum process > SCHED_RR priority for use with sched_setschedparam() or does it tell me the > maximum thread SCHED_RR priority for use with pthread_setschedparam()? The functions sched_getparam(), sched_setparam() are listed as cross-references, while pthread_setschedparam() is not. It's probably also useful to look at the pthread_setschedparam() cross-references, which include pthread_setschedprio(). The page for that function contains a rationale section, and references the System Interfaces, Section 2, bsection "Scheduling Policies": It specifically states that there shall be a minimum specified, but that the maximum is implementation defined. This reinforces the idea that sched_get_priority_max() is meaningful to sched_* functions, but not in pthread_* functions. I suppose if you wanted to get technical on meaning, you could *maybe* interpret the results in the context of whether or not the calling thread was "scope process" or "scope system", and return a meaningful value under those circumstances. Of course, that would be evil. 8-). Personally, I would note that the extension sections the set commands are located in are disjoint, and that you are probably in territory that's, at best, "implementation defined", when it comes to trying to find allowable argument values for pthread_setschedparam(). -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 09:33: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 A802437B401 for ; Wed, 9 Jul 2003 09:33:09 -0700 (PDT) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECD1243F75 for ; Wed, 9 Jul 2003 09:33:08 -0700 (PDT) (envelope-from kai.mosebach@freshx.de) Received: from alpha (p508B29F1.dip.t-dialin.net [80.139.41.241]) by dust.freshx.de (Postfix) with ESMTP id 05D1115E206 for ; Wed, 9 Jul 2003 18:33:00 +0200 (CEST) From: "Kai Mosebach" To: Date: Wed, 9 Jul 2003 18:33:06 +0200 Message-ID: <001a01c34637$c7bca340$0100a8c0@alpha> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: LinuxThreads replacement 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: Wed, 09 Jul 2003 16:33:09 -0000 Hi, can libthr / libkse easily be used as a liblthreads (LinuxThreads) replacement ? cheers Kai From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 09:40:25 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 3774837B401 for ; Wed, 9 Jul 2003 09:40:25 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 287E743F85 for ; Wed, 9 Jul 2003 09:40:24 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h69GeMsL031499; Wed, 9 Jul 2003 19:40:22 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <004201c34638$c693be30$812a40c1@PETEX31> From: "Petri Helenius" To: "Kai Mosebach" , References: <001a01c34637$c7bca340$0100a8c0@alpha> Date: Wed, 9 Jul 2003 19:40:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: LinuxThreads replacement 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: Wed, 09 Jul 2003 16:40:25 -0000 > Hi, > > can libthr / libkse easily be used as a liblthreads (LinuxThreads) > replacement ? > Sure and you get to keep your SIGUSR1 and SIGUSR2 signals too. And thread switching overhead is much less if you use libkse, somewhat similar with libthr. (though I havenŽt run exact performance tests since linuxthreads had some snags I never really got hold of) Pete From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 09:41:37 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 08DD437B401 for ; Wed, 9 Jul 2003 09:41:37 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC1343F3F for ; Wed, 9 Jul 2003 09:41:36 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h69GfXAI004397; Wed, 9 Jul 2003 12:41:33 -0400 (EDT) Date: Wed, 9 Jul 2003 12:41:33 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Kai Mosebach In-Reply-To: <001a01c34637$c7bca340$0100a8c0@alpha> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement 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: Wed, 09 Jul 2003 16:41:37 -0000 On Wed, 9 Jul 2003, Kai Mosebach wrote: > Hi, > > can libthr / libkse easily be used as a liblthreads (LinuxThreads) > replacement ? I would doubt that you'd be able to copy (or use libmap.conf) libthr/libkse over liblthreads. I suspect that the mutex types (and perhaps others) may be implemented differently so that their sizes are incompatible. For instance, if linuxthreads defines pthread_mutex_t as a struct, that wouldn't work when FreeBSD defines them to be pointers to structs. Actually, maybe that would work since the FreeBSD types are not greater in size. But there are other possible problems -- pthread_cleanup_push() implemented as macros in linuxthreads for one. On the other hand, if you want to recompile something that currently uses linuxthreads, it should work using one of our thread libraries. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 09:49:28 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 B3ACE37B401; Wed, 9 Jul 2003 09:49:28 -0700 (PDT) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B7143F93; Wed, 9 Jul 2003 09:49:27 -0700 (PDT) (envelope-from kai.mosebach@freshx.de) Received: from alpha (p508B29F1.dip.t-dialin.net [80.139.41.241]) by dust.freshx.de (Postfix) with ESMTP id 07E1115E10E; Wed, 9 Jul 2003 18:49:19 +0200 (CEST) From: "Kai Mosebach" To: Date: Wed, 9 Jul 2003 18:49:25 +0200 Message-ID: <001b01c3463a$0f907a00$0100a8c0@alpha> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal cc: freebsd-threads@freebsd.org Subject: AW: LinuxThreads replacement 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: Wed, 09 Jul 2003 16:49:29 -0000 Currently, im porting the SapDB (www.sapdb.org) to FreeBSD (www.komadev.de/sapdb), which makes heavy use of the lthreads, but 1.) isnt running stable on 5.1 (not sure whether its a lthreads problem) 2.) is not the fastest (i guess) 3.) has more (especially memory) overhead for example, for on database instance, there are about 80 (lthread) processes hanging around. So i thought of a simple complete recompiling. Would you more likely use libthr or libkse,=20 as kse is not complete yet, isnt it ? regards -----Urspr=FCngliche Nachricht----- Von: Daniel Eischen [mailto:eischen@vigrid.com]=20 Gesendet: Mittwoch, 9. Juli 2003 18:42 An: Kai Mosebach Cc: freebsd-threads@freebsd.org Betreff: Re: LinuxThreads replacement On Wed, 9 Jul 2003, Kai Mosebach wrote: > Hi, >=20 > can libthr / libkse easily be used as a liblthreads (LinuxThreads) > replacement ? I would doubt that you'd be able to copy (or use libmap.conf) libthr/libkse over liblthreads. I suspect that the mutex types (and perhaps others) may be implemented differently so that their sizes are incompatible. For instance, if linuxthreads defines pthread_mutex_t as a struct, that wouldn't work when FreeBSD defines them to be pointers to structs. Actually, maybe that would work since the FreeBSD types are not greater in size. But there are other possible problems -- pthread_cleanup_push() implemented as macros in linuxthreads for one. On the other hand, if you want to recompile something that currently uses linuxthreads, it should work using one of our thread libraries. --=20 Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 11:59:55 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 271A337B401 for ; Wed, 9 Jul 2003 11:59:55 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89AA743F85 for ; Wed, 9 Jul 2003 11:59:54 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h69IxrAI027476; Wed, 9 Jul 2003 14:59:53 -0400 (EDT) Date: Wed, 9 Jul 2003 14:59:53 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Kai Mosebach In-Reply-To: <001b01c3463a$0f907a00$0100a8c0@alpha> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: AW: LinuxThreads replacement 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: Wed, 09 Jul 2003 18:59:55 -0000 On Wed, 9 Jul 2003, Kai Mosebach wrote: > Currently, im porting the SapDB (www.sapdb.org) to FreeBSD > (www.komadev.de/sapdb), which makes heavy use of the lthreads, but > > 1.) isnt running stable on 5.1 (not sure whether its a lthreads problem) > 2.) is not the fastest (i guess) > 3.) has more (especially memory) overhead > > for example, for on database instance, there are about 80 (lthread) > processes hanging around. > > So i thought of a simple complete recompiling. > > Would you more likely use libthr or libkse, > as kse is not complete yet, isnt it ? KSE seems to be working pretty well for me. I'd suggest giving it a try. Once you compile with either libthr or libkse, you can easily use the other library just by copying one over the other or by using libmap.conf. To date, both libthr and libkse can be drop-in replacements for the other (and libc_r). If you have problems getting SapDB to compile with libthr or libkse, try libc_r (due to some autoconfig and libtool assumptions, it may be easier to use libc_r). Once you get it built with libc_r, you can drop-in libthr or libkse for libc_r. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 12:11:25 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 0957237B401; Wed, 9 Jul 2003 12:11:25 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id B310343F85; Wed, 9 Jul 2003 12:11:23 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h69JBMsL032596; Wed, 9 Jul 2003 22:11:22 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <006401c3464d$de848a00$812a40c1@PETEX31> From: "Petri Helenius" To: "Kai Mosebach" , References: <001b01c3463a$0f907a00$0100a8c0@alpha> Date: Wed, 9 Jul 2003 22:11:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement 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: Wed, 09 Jul 2003 19:11:25 -0000 >for example, for on database instance, there are about 80 (lthread) >processes hanging around. I would say with 80 threads youŽll get better performance with libkse since youŽll get less contention on the process scheduler. Pete From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 14:36:49 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 1257837B401; Wed, 9 Jul 2003 14:36:49 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6645843FA3; Wed, 9 Jul 2003 14:36:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc13) with ESMTP id <20030709213648015007amt0e>; Wed, 9 Jul 2003 21:36:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA33228; Wed, 9 Jul 2003 14:36:42 -0700 (PDT) Date: Wed, 9 Jul 2003 14:36:41 -0700 (PDT) From: Julian Elischer To: Petri Helenius In-Reply-To: <3F0A7425.9080300@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority with libkse 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: Wed, 09 Jul 2003 21:36:49 -0000 On Tue, 8 Jul 2003, Petri Helenius wrote: > Daniel Eischen wrote: > > >The current thread. As I said before, if there are idle KSEs, then > >one is woken to run the newly runnable thread. > > > I'm seeing about 200 microsecond latency when scheduling the thread on > the other > KSE. Which translates to maximum of 2500 "spins" of the contested loop > a second. > As I said in othe rmail.. try setting machdep.cpu_idle_hlt to 0 > Same code runs about 500000 spins a second when no locking is involved. > > This is on othervise idle Dual 2.4 Xeon. > > If the mutex performance sounds about right, I need to redesign my > locking to > go from one contested lock to many uncontested ones, which sounds a good > idea > anyway. > > >It waits until either you hit a blocking condition or the > >quantum expires. The library is not (yet) smart enough > >to switch out the current thread after the unlock if the > >new owner has a higher priority. We could do that, but > >if there are other KSEs that can run the new thread, then > >they should get it. > > > > > > > But the library is smart enough to extend the quantum on a higher > priority thread if SCHED_RR is in effect? I'm seeing multiples > of 20ms being allocated with two runnable threads of priorities > 15 and 20 competing for the CPU. > > Pete > > > _______________________________________________ > 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 Wed Jul 9 16:52:25 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 E577137B401 for ; Wed, 9 Jul 2003 16:52:24 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-181-146.esr.east.verizon.net [141.156.181.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBCC643F3F for ; Wed, 9 Jul 2003 16:52:23 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (localhost [IPv6:::1]) id h69NqM0G010801; Wed, 9 Jul 2003 19:52:23 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.6/Submit) id h69NqMHr010800; Wed, 9 Jul 2003 19:52:22 -0400 (EDT) (envelope-from mtm@identd.net) Date: Wed, 9 Jul 2003 19:52:22 -0400 From: Mike Makonnen To: Kai Mosebach Message-ID: <20030709235221.GA10504@kokeb.ambesa.net> References: <001b01c3463a$0f907a00$0100a8c0@alpha> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <001b01c3463a$0f907a00$0100a8c0@alpha> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement 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: Wed, 09 Jul 2003 23:52:25 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 09, 2003 at 06:49:25PM +0200, Kai Mosebach wrote: > > Would you more likely use libthr or libkse, > as kse is not complete yet, isnt it ? > Either one should work just as well. There is currently a race in the kernel code for libthr that can lead to deadlocks. I have a fix for this and I am waiting for jeff to review it before I commit it. In the mean time you can get the patch here: http://people.freebsd.org/~mtm/patches/libthr.kern.diff (also attached) Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="umtx3.diff" Index: sys/kern/kern_umtx.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_umtx.c,v retrieving revision 1.7 diff -u -r1.7 kern_umtx.c --- sys/kern/kern_umtx.c 4 Jul 2003 23:28:42 -0000 1.7 +++ sys/kern/kern_umtx.c 5 Jul 2003 05:53:02 -0000 @@ -181,7 +181,7 @@ return (EFAULT); if (owner == UMTX_CONTESTED) - return (0); + goto out; /* If this failed the lock has changed, restart. */ continue; @@ -190,7 +190,6 @@ UMTX_LOCK(); uq = umtx_insert(td, umtx); - UMTX_UNLOCK(); /* * Set the contested bit so that a release in user space @@ -203,7 +202,6 @@ /* The address was invalid. */ if (old == -1) { - UMTX_LOCK(); umtx_remove(uq, td); UMTX_UNLOCK(); return (EFAULT); @@ -213,7 +211,6 @@ * We set the contested bit, sleep. Otherwise the lock changed * and we need to retry. */ - UMTX_LOCK(); if (old == owner) error = msleep(td, &umtx_lock, td->td_priority | PCATCH, "umtx", 0); @@ -230,8 +227,37 @@ if (error) return (error); } - - return (0); +out: + /* + * We reach here only if we just acquired a contested umtx. + * + * If there are no other threads on this umtx's queue + * clear the contested bit. However, we cannot hold + * a lock across casuptr(). So after we unset it we + * have to recheck, and set it again if another thread has + * put itself on the queue in the mean time. + */ + error = 0; + UMTX_LOCK(); + uq = umtx_lookup(td, umtx); + UMTX_UNLOCK(); + if (uq == NULL) + old = casuptr((intptr_t *)&umtx->u_owner, + ((intptr_t)td | UMTX_CONTESTED), (intptr_t)td); + if (uq == NULL && old == ((intptr_t)td | UMTX_CONTESTED)) { + UMTX_LOCK(); + uq = umtx_lookup(td, umtx); + UMTX_UNLOCK(); + if (uq != NULL) { + old = casuptr((intptr_t *)&umtx->u_owner, + (intptr_t)td, ((intptr_t)td | UMTX_CONTESTED)); + if (old == -1) + error = EFAULT; + else if (old != (intptr_t)td) + error = EINVAL; + } + } + return (error); } int @@ -257,25 +283,9 @@ if ((struct thread *)(owner & ~UMTX_CONTESTED) != td) return (EPERM); - /* - * If we own it but it isn't contested then we can just release and - * return. - */ - if ((owner & UMTX_CONTESTED) == 0) { - owner = casuptr((intptr_t *)&umtx->u_owner, - (intptr_t)td, UMTX_UNOWNED); - if (owner == -1) - return (EFAULT); - /* - * If this failed someone modified the memory without going - * through this api. - */ - if (owner != (intptr_t)td) - return (EINVAL); - - return (0); - } + /* We should only ever be in here for contested locks */ + KASSERT((owner & UMTX_CONTESTED) != 0, ("contested umtx is not.")); old = casuptr((intptr_t *)&umtx->u_owner, owner, UMTX_CONTESTED); @@ -296,6 +306,7 @@ uq = umtx_lookup(td, umtx); if (uq != NULL) { blocked = TAILQ_FIRST(&uq->uq_tdq); + KASSERT(blocked != NULL, ("umtx_q with no waiting threads.")); wakeup(blocked); } --oyUTqETQ0mS9luUI-- From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 17:12:20 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 D5E7637B401 for ; Wed, 9 Jul 2003 17:12:20 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-181-146.esr.east.verizon.net [141.156.181.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38BE343FAF for ; Wed, 9 Jul 2003 17:12:16 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (localhost [IPv6:::1]) id h6A0C80G010909; Wed, 9 Jul 2003 20:12:08 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.6/Submit) id h6A0C4ok010908; Wed, 9 Jul 2003 20:12:04 -0400 (EDT) (envelope-from mtm@identd.net) Date: Wed, 9 Jul 2003 20:12:04 -0400 From: Mike Makonnen To: Petri Helenius Message-ID: <20030710001204.GB10504@kokeb.ambesa.net> References: <001b01c3463a$0f907a00$0100a8c0@alpha> <006401c3464d$de848a00$812a40c1@PETEX31> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006401c3464d$de848a00$812a40c1@PETEX31> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) cc: Kai Mosebach cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement 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: Thu, 10 Jul 2003 00:12:21 -0000 On Wed, Jul 09, 2003 at 10:11:15PM +0300, Petri Helenius wrote: > >for example, for on database instance, there are about 80 (lthread) > >processes hanging around. > > I would say with 80 threads you?ll get better performance with libkse > since you?ll get less contention on the process scheduler. > It's not as simple as that. In practice a lot of factors about your system and the type of work you're doing will affect the performance. On paper, the SA/KSE method is supposed to combine the best aspects of 1:1 (libthr) and N:1 (libc_r), and should threoretically be "better" than either one. But, in practice, complexity and overhead may drown out the performance gains. Conversely, context switching overhead may not be as great a penalty for the 1:1 model on modern cpus. I don't want to get in a flamewar over this. I just wanted to point out that it's not as simple as "contention on the process scheduler." I think what we need, now that both libthr and libkse are somewhat useable, is some benchmarking comparisons. If you have the time I think we would all be interested to see any performance comparisons you can run with your application. Once you compile the application switching threads libraries is as simple as editing /etc/libmap.conf. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 17:17:47 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 E3E4F37B401 for ; Wed, 9 Jul 2003 17:17:47 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685C943FBD for ; Wed, 9 Jul 2003 17:17:47 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h6A0Hiib011877 for ; Wed, 9 Jul 2003 17:17:44 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h6A0Hi6d011876 for freebsd-threads@freebsd.org; Wed, 9 Jul 2003 17:17:44 -0700 Date: Wed, 9 Jul 2003 17:17:44 -0700 From: Brooks Davis To: freebsd-threads@freebsd.org Message-ID: <20030710001744.GA7135@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Subject: null pthread_t 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: Thu, 10 Jul 2003 00:17:48 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've got some Linux pthread code that goes something like this that I'm porting to FreeBSD: ------ pthread_t tid; tid =3D -1; /* Do stuff including maybe creating a thread. */ if (tid !=3D -1) { pthread_cancel(tid); pthread_join(tid, NULL); } ------ Since FreeBSD uses pointers instead of integers for pthread_t's, this generates warnings which go away if you replace -1 with NULL, but it seems like that is likely to do bad things on linux. Is there a portable NULL-equivalent pthread_t? I'm not seeing anything jump out at me in the headers. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/DLCnXY6L6fI4GtQRAjHNAKDUn1xykRWJxSo67Is/tvLhZAF09wCePdb+ adY9Ah11B/6HDE1Oe9g1evA= =gWeh -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 18:06: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 C2EC637B401 for ; Wed, 9 Jul 2003 18:06:07 -0700 (PDT) Received: from postoffice.e-easy.com.au (eth0.lnk.e-easy.com.au [203.31.73.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id A99EC43F75 for ; Wed, 9 Jul 2003 18:06:05 -0700 (PDT) (envelope-from chris@e-easy.com.au) Received: from postoffice.aims.com.au (nts-ts1.aims.private [192.168.10.2]) by postoffice.e-easy.com.au with ESMTP id h6A15ujY017247 for ; Thu, 10 Jul 2003 11:05:56 +1000 (EST) (envelope-from chris@e-easy.com.au) Received: from ntsts1 by aims.com.au (MDaemon.PRO.v6.8.4.R) with ESMTP id 20-md50000000087.tmp for ; Thu, 10 Jul 2003 10:36:58 +1000 From: "Chris Knight" To: "'Kai Mosebach'" , Date: Thu, 10 Jul 2003 10:36:57 +1000 Message-ID: <007601c3467b$5f20e960$020aa8c0@aims.private> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Spam-Processed: aims.com.au, Thu, 10 Jul 2003 10:36:58 +1000 (not processed: spam filter disabled) X-Return-Path: chris@e-easy.com.au X-MDaemon-Deliver-To: freebsd-threads@freebsd.org X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-4.0 required=4.6 tests=AWL,BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: RE: LinuxThreads replacement 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: Thu, 10 Jul 2003 01:06:08 -0000 Howdy, Be aware that FreeBSD threads implementation mostly conforms to SUSv2, where linuxthreads mostly conforms to SUSv3, so if your code relies of SUSv3 features you're stuck with linuxthreads. (ie pthread_spin_* and pthread_barrier_* function calls). I could of course be completely wrong, as I'm still trying to get up to speed with thread implementations. Is it just me, or are threads just a complete evil, which very few people understand correctly and are able to implement and/or use them correctly? Regards, Chris Knight Systems Administrator E-Easy Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.e-easy.com.au > -----Original Message----- > From: Kai Mosebach [mailto:kai.mosebach@freshx.de] > Sent: Thursday, 10 July 2003 2:33 > To: freebsd-threads@freebsd.org > Subject: LinuxThreads replacement > > > Hi, > > can libthr / libkse easily be used as a liblthreads (LinuxThreads) > replacement ? > > cheers Kai From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 19:47:13 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21CCC37B401 for ; Wed, 9 Jul 2003 19:47:13 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62E6D43FB1 for ; Wed, 9 Jul 2003 19:47:12 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h6A2lBAI010072; Wed, 9 Jul 2003 22:47:11 -0400 (EDT) Date: Wed, 9 Jul 2003 22:47:10 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Brooks Davis In-Reply-To: <20030710001744.GA7135@Odin.AC.HMC.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: null pthread_t 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: Thu, 10 Jul 2003 02:47:13 -0000 On Wed, 9 Jul 2003, Brooks Davis wrote: > I've got some Linux pthread code that goes something like this that I'm > porting to FreeBSD: > > ------ > pthread_t tid; > > tid = -1; > > /* Do stuff including maybe creating a thread. */ > > if (tid != -1) { > pthread_cancel(tid); > pthread_join(tid, NULL); > } > ------ > > Since FreeBSD uses pointers instead of integers for pthread_t's, this > generates warnings which go away if you replace -1 with NULL, but > it seems like that is likely to do bad things on linux. Is there a > portable NULL-equivalent pthread_t? I'm not seeing anything jump out at > me in the headers. The code in question shouldn't be doing that. If it needs to know whether a thread id is valid, it should have a separate flag for it (tid_valid) or possibly use pthread_kill(tid, 0) and checking the return value (sending signal 0 to a thread is akin to sending a process signal 0; the signal isn't delivered but the process id is checked for validity). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 22:54:37 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 4338937B401 for ; Wed, 9 Jul 2003 22:54:37 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0946A43F85 for ; Wed, 9 Jul 2003 22:54:36 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h6A5sWsL036739 for ; Thu, 10 Jul 2003 08:54:34 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F0CFF98.6010409@he.iki.fi> Date: Thu, 10 Jul 2003 08:54:32 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: 4.8 and 5.1 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: Thu, 10 Jul 2003 05:54:37 -0000 Are the data structures between 4.8 and 5.1 compatible so I could compile code that would run both with libc_r on 4.8 and libkse on 5.1 using libmap.conf ? Pete From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 00:35:06 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 0D7E637B401 for ; Thu, 10 Jul 2003 00:35:06 -0700 (PDT) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6865943F85 for ; Thu, 10 Jul 2003 00:35:05 -0700 (PDT) (envelope-from kai.mosebach@freshx.de) Received: from alpha (p508B1B44.dip.t-dialin.net [80.139.27.68]) by dust.freshx.de (Postfix) with ESMTP id 47A9B15E205; Thu, 10 Jul 2003 09:35:00 +0200 (CEST) From: "Kai Mosebach" To: "'Mike Makonnen'" , "'Petri Helenius'" Date: Thu, 10 Jul 2003 09:35:03 +0200 Message-ID: <000301c346b5$c8327240$0100a8c0@alpha> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030710001204.GB10504@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org Subject: AW: LinuxThreads replacement 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: Thu, 10 Jul 2003 07:35:06 -0000 Hi, Hmm, some kind of benchmark would be pretty interesting, thats right. But im not sure, whether its done by simply switching between the lib in the Libmap.conf, because sapdb consists of ~50 executables, which are startet from each other (for example, you have a service listener, which starts a dm-manager, and later on a database-kernel and so on ...), so i guess, that i have to whether 1) link libc_r or some nasty trick like that, or to create to binary versions. cheers -----Urspr=FCngliche Nachricht----- Von: Mike Makonnen [mailto:mtm@identd.net]=20 Gesendet: Donnerstag, 10. Juli 2003 02:12 An: Petri Helenius Cc: Kai Mosebach; freebsd-threads@freebsd.org Betreff: Re: LinuxThreads replacement On Wed, Jul 09, 2003 at 10:11:15PM +0300, Petri Helenius wrote: > >for example, for on database instance, there are about 80 (lthread) > >processes hanging around. >=20 > I would say with 80 threads you?ll get better performance with libkse > since you?ll get less contention on the process scheduler. >=20 It's not as simple as that. In practice a lot of factors about your system and the type of work you're doing will affect the performance. On paper, the SA/KSE method is supposed to combine the best aspects of 1:1 (libthr) and N:1 (libc_r), and should threoretically be "better" than either one. But, in practice, complexity and overhead may drown out the performance gains. Conversely, context switching overhead may not be as great a penalty for the 1:1 model on modern cpus. I don't want to get in a flamewar over this. I just wanted to point out that it's not as simple as "contention on the process scheduler." I think what we need, now that both libthr and libkse are somewhat useable, is some benchmarking comparisons. If you have the time I think we would all be interested to see any performance comparisons you can run with your application. Once you compile the application switching threads libraries is as simple as editing /etc/libmap.conf. Cheers. --=20 Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 00:39:33 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 5E14337B401 for ; Thu, 10 Jul 2003 00:39:33 -0700 (PDT) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id A890A43FA3 for ; Thu, 10 Jul 2003 00:39:32 -0700 (PDT) (envelope-from kai.mosebach@freshx.de) Received: from alpha (p508B1B44.dip.t-dialin.net [80.139.27.68]) by dust.freshx.de (Postfix) with ESMTP id 2E00A15E1FC for ; Thu, 10 Jul 2003 09:39:28 +0200 (CEST) From: "Kai Mosebach" To: Date: Thu, 10 Jul 2003 09:39:31 +0200 Message-ID: <000401c346b6$67b911c0$0100a8c0@alpha> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: Kse/Thr _exit implementation 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: Thu, 10 Jul 2003 07:39:33 -0000 Hi again, i have two other questions regarding the kse/thr implementation: 1.) often i see, that the linuxthreads implematation has problems with the exit() function, if not all threads are finished. Is this fixed in kse ? 2.) i found this piece of code in the sapdb, which had to be enabled, when i used linuxthreads, but with kse it just loops around, so i removed it. Is this problem described here lthreads only ? cheers ------------------------snip #if defined LINUX || (defined FREEBSD && defined LINUXTHREADS && !defined FREEBSD_THREADS) if ( pThreadObj->StackSize != 0 ) /* PTS 1106187 */ { /* * Some words.... PTS 1105262/1105263 * There was a LINUX specific crash without this YIELD_CALL loop. The linuxthread * pthread manager does not synchronize the pthread_join() call with the actions * of freeing internal references to the joined thread. Since these references are * situated on the pthread stack, freeing this stack results in program crashes depending * on the scheduling. Forcing the join to wait until the thread actually was terminating * solves part of this problem. Creating another dummy thread solves the synchronization. */ /* PTS 1105678 poll after join not before join... and use kill instead of pthread_kill */ while ( kill( pThreadObj->thread_id, 0) == 0 ) { sleep(1); /* YIELD_CALL; */ /* let him finsh */ } } #endif From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 01:13:26 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D390137B401 for ; Thu, 10 Jul 2003 01:13:26 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-181-146.esr.east.verizon.net [141.156.181.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1663843FAF for ; Thu, 10 Jul 2003 01:13:24 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (localhost [IPv6:::1]) id h6A8DK0G014675; Thu, 10 Jul 2003 04:13:20 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.6/Submit) id h6A8DJ9S014674; Thu, 10 Jul 2003 04:13:19 -0400 (EDT) (envelope-from mtm@identd.net) Date: Thu, 10 Jul 2003 04:13:19 -0400 From: Mike Makonnen To: Kai Mosebach Message-ID: <20030710081318.GA14524@kokeb.ambesa.net> References: <20030710001204.GB10504@kokeb.ambesa.net> <000301c346b5$c8327240$0100a8c0@alpha> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000301c346b5$c8327240$0100a8c0@alpha> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement 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: Thu, 10 Jul 2003 08:13:27 -0000 On Thu, Jul 10, 2003 at 09:35:03AM +0200, Kai Mosebach wrote: > Hi, > > Hmm, some kind of benchmark would be pretty interesting, thats right. > But im not sure, whether its done by simply switching between the lib in > the > Libmap.conf, because sapdb consists of ~50 executables, which are > startet from each other (for example, you have a service listener, which > starts a dm-manager, and later on a database-kernel and so on ...), so i > guess, that i have to whether 1) link libc_r or some nasty trick like > that, or to create to binary versions. > I'm not sure I understand what you are saying. To begin with you should go to /usr/src/libexec/rtld-elf and do a make clean; make depend && make -DWITH_LIBMAP && make install Assuming, that whatever you're porting is NOT statically linked, then all you have to do is edit /etc/libmap.conf; for example: # global mappings libc_r.so.5 libkse.so.1 libc_r.so libkse.so and then start the application. Any executables that are started after that and are linked to libc_r, will instead link with libkse. Then, you stop the database, and edit libmap.conf to point to libthr. Then, startup the database. For more information: man libmap.conf. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 01:22:03 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 D040837B401 for ; Thu, 10 Jul 2003 01:22:03 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51CA843FCB for ; Thu, 10 Jul 2003 01:22:02 -0700 (PDT) (envelope-from davidxu@viatech.com.cn) Received: from davidw2k (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3MLFXGNH; Thu, 10 Jul 2003 16:05:42 +0800 Message-ID: <002601c346bc$cb49c030$f001a8c0@davidw2k> From: "David Xu" To: "Kai Mosebach" , References: <000401c346b6$67b911c0$0100a8c0@alpha> Date: Thu, 10 Jul 2003 16:25:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: Kse/Thr _exit implementation 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: Thu, 10 Jul 2003 08:22:04 -0000 ----- Original Message -----=20 From: "Kai Mosebach" To: Sent: Thursday, July 10, 2003 3:39 PM Subject: Kse/Thr _exit implementation > Hi again, >=20 > i have two other questions regarding the kse/thr implementation: >=20 > 1.) often i see, that the linuxthreads implematation has problems with > the > exit() function, if not all threads are finished. Is this fixed in kse = ? >=20 exit() is OK on FreeBSD for multiple threads process, I never heard threaded process has exit() problem with libkse/libthr. > 2.) i found this piece of code in the sapdb, which had to be enabled, > when i used linuxthreads, but with kse it just loops around, so i > removed it. Is this problem described here lthreads only ? >=20 > cheers=20 >=20 > ------------------------snip >=20 > #if defined LINUX || (defined FREEBSD && defined LINUXTHREADS && > !defined FREEBSD_THREADS) > if ( pThreadObj->StackSize !=3D 0 ) /* PTS 1106187 */ > { > /* > * Some words.... PTS 1105262/1105263 > * There was a LINUX specific crash without this YIELD_CALL loop. > The linuxthread=20 > * pthread manager does not synchronize the pthread_join() call = with > the actions > * of freeing internal references to the joined thread. Since = these > references are > * situated on the pthread stack, freeing this stack results in > program crashes depending > * on the scheduling. Forcing the join to wait until the thread > actually was terminating > * solves part of this problem. Creating another dummy thread = solves > the synchronization. > */ > /* PTS 1105678 poll after join not before join... and use kill > instead of pthread_kill */ > while ( kill( pThreadObj->thread_id, 0) =3D=3D 0 ) > { > sleep(1); /* YIELD_CALL; */ /* let him finsh */ > } > } > #endif >=20 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to = "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 01:22:59 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 2E60A37B401 for ; Thu, 10 Jul 2003 01:22:59 -0700 (PDT) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9140C43F85 for ; Thu, 10 Jul 2003 01:22:58 -0700 (PDT) (envelope-from kai.mosebach@freshx.de) Received: from alpha (p508B3A6D.dip.t-dialin.net [80.139.58.109]) by dust.freshx.de (Postfix) with ESMTP id D2EFD15E10E; Thu, 10 Jul 2003 10:22:53 +0200 (CEST) From: "Kai Mosebach" To: "'Mike Makonnen'" Date: Thu, 10 Jul 2003 10:22:58 +0200 Message-ID: <000501c346bc$78fdf0d0$0100a8c0@alpha> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030710081318.GA14524@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org Subject: AW: LinuxThreads replacement 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: Thu, 10 Jul 2003 08:22:59 -0000 > > Hi, > > > > Hmm, some kind of benchmark would be pretty interesting, thats right. > > But im not sure, whether its done by simply switching between the lib in > > the > > Libmap.conf, because sapdb consists of ~50 executables, which are > > startet from each other (for example, you have a service listener, which > > starts a dm-manager, and later on a database-kernel and so on ...), so i > > guess, that i have to whether 1) link libc_r or some nasty trick like > > that, or to create to binary versions. > > > > I'm not sure I understand what you are saying. > > To begin with you should go to /usr/src/libexec/rtld-elf and do a > make clean; make depend && make -DWITH_LIBMAP && make install > > Assuming, that whatever you're porting is NOT statically linked, then > all you have to do is edit /etc/libmap.conf; for example: > # global mappings > libc_r.so.5 libkse.so.1 > libc_r.so libkse.so OK, that would bet the best way for performance testings i guess. I was just aware of the possibility of mapping a lib to an executable ... > > and then start the application. Any executables that are started > after that and are linked to libc_r, will instead link with > libkse. Then, you stop the database, and edit libmap.conf to > point to libthr. Then, startup the database. > For more information: man libmap.conf. > > Cheers. > -- > Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc > mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 > mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 03:22:25 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 AA25E37B401 for ; Thu, 10 Jul 2003 03:22:25 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A70943F85 for ; Thu, 10 Jul 2003 03:22:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfjrs.dialup.mindspring.com ([165.247.207.124] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19aYZ9-0003fi-00; Thu, 10 Jul 2003 03:22:20 -0700 Message-ID: <3F0D3E1D.F26FA9E1@mindspring.com> Date: Thu, 10 Jul 2003 03:21:17 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Makonnen References: <001b01c3463a$0f907a00$0100a8c0@alpha> <20030710001204.GB10504@kokeb.ambesa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43df10a0ee0c97f68809d6e40539e6099387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: Kai Mosebach cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement 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: Thu, 10 Jul 2003 10:22:26 -0000 Mike Makonnen wrote: > On Wed, Jul 09, 2003 at 10:11:15PM +0300, Petri Helenius wrote: > > >for example, for on database instance, there are about 80 (lthread) > > >processes hanging around. > > > > I would say with 80 threads you?ll get better performance with libkse > > since you?ll get less contention on the process scheduler. > > It's not as simple as that. In practice a lot of factors about > your system and the type of work you're doing will affect the > performance. On paper, the SA/KSE method is supposed to combine > the best aspects of 1:1 (libthr) and N:1 (libc_r), and should > threoretically be "better" than either one. But, in practice, > complexity and overhead may drown out the performance gains. > Conversely, context switching overhead may not be as great a > penalty for the 1:1 model on modern cpus. The most intersting issue is that the pthread_setconcurrency() controls how many blocking contexts (KSEGs) you have available. If process space is at a premium, you can scale to a much larger number with KSE than you would be able to with Linux threads, since with KSE, the threads are really rather light-weight user space things. You made a statement before that you had 80 threads, and with Linux threads, you were feeling it at 80. I wasn't sure from the context whether you meant 80 was to many for your system or 80 was too few for your application, so I didn't say anything before. But this could definitely be a big factor in your choice of threading library, given your previous statement. -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 03:25:56 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 990D737B401 for ; Thu, 10 Jul 2003 03:25:56 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27B9A43FB1 for ; Thu, 10 Jul 2003 03:25:56 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfjrs.dialup.mindspring.com ([165.247.207.124] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19aYcd-0003zM-00; Thu, 10 Jul 2003 03:25:55 -0700 Message-ID: <3F0D3EF6.A9000297@mindspring.com> Date: Thu, 10 Jul 2003 03:24:54 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis References: <20030710001744.GA7135@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43df10a0ee0c97f68bd1f5a0c04e73e3ba2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-threads@freebsd.org Subject: Re: null pthread_t 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: Thu, 10 Jul 2003 10:25:56 -0000 Brooks Davis wrote: > Since FreeBSD uses pointers instead of integers for pthread_t's, this > generates warnings which go away if you replace -1 with NULL, but > it seems like that is likely to do bad things on linux. Is there a > portable NULL-equivalent pthread_t? I'm not seeing anything jump out at > me in the headers. pthread_t PTHREAD_NULL; /* global NULL equivalent */ pthread_t ptr; ... if( ptr == PTHREAD_NULL) Basically, the type will be a BSS zero'ed global "NULL" in both compilation environments, and the comparison will "just work" because the type will be right. -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 05:48:39 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 C209C37B401 for ; Thu, 10 Jul 2003 05:48:39 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C6F43FB1 for ; Thu, 10 Jul 2003 05:48:38 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h6ACmZAI004632; Thu, 10 Jul 2003 08:48:37 -0400 (EDT) Date: Thu, 10 Jul 2003 08:48:35 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <3F0CFF98.6010409@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: 4.8 and 5.1 threads 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: Thu, 10 Jul 2003 12:48:40 -0000 On Thu, 10 Jul 2003, Petri Helenius wrote: > > Are the data structures between 4.8 and 5.1 compatible so I could > compile code > that would run both with libc_r on 4.8 and libkse on 5.1 using libmap.conf ? I don't think that would work for a variety of reasons, mostly because of libc incompatibilities between 4.x and 5.x. Also because you don't link to libc on 4.x because it is included in 5.1. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Jul 10 05:58: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 EF8E037B401 for ; Thu, 10 Jul 2003 05:58:04 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 551A943F3F for ; Thu, 10 Jul 2003 05:58:04 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h6ACw3AI005955; Thu, 10 Jul 2003 08:58:03 -0400 (EDT) Date: Thu, 10 Jul 2003 08:58:03 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Terry Lambert In-Reply-To: <3F0D3EF6.A9000297@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brooks Davis cc: freebsd-threads@freebsd.org Subject: Re: null pthread_t 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: Thu, 10 Jul 2003 12:58:05 -0000 On Thu, 10 Jul 2003, Terry Lambert wrote: > Brooks Davis wrote: > > Since FreeBSD uses pointers instead of integers for pthread_t's, this > > generates warnings which go away if you replace -1 with NULL, but > > it seems like that is likely to do bad things on linux. Is there a > > portable NULL-equivalent pthread_t? I'm not seeing anything jump out at > > me in the headers. > > pthread_t PTHREAD_NULL; /* global NULL equivalent */ > > pthread_t ptr; > > > ... > > if( ptr == PTHREAD_NULL) > > Basically, the type will be a BSS zero'ed global "NULL" in both > compilation environments, and the comparison will "just work" > because the type will be right. This doesn't work where pthread_t's are integer id's (perhaps used as indices into a lookup table to find the real pointer). An index of 0 may be a valid thread id (which is why I assume it was set to -1 in Linux). Unless you are advocating defining PTHREAD_NULL differently depending on the threads implementation... But the code should be rewritten to use a different method of validating the thread (use a flag, or encapsulate it in an application defined type along with a flag). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jul 11 02:37:56 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 57BD537B401; Fri, 11 Jul 2003 02:37:56 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1BFC43F75; Fri, 11 Jul 2003 02:37:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from dialup-67.30.108.143.dial1.sanjose1.level3.net ([67.30.108.143] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19auLi-00067N-00; Fri, 11 Jul 2003 02:37:55 -0700 Message-ID: <3F0E8496.CBDCC23B@mindspring.com> Date: Fri, 11 Jul 2003 02:34:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: deischen@freebsd.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a49f79a1d2488bc0b77f1cf69d60f553752601a10902912494350badd9bab72f9c350badd9bab72f9c cc: Brooks Davis cc: freebsd-threads@freebsd.org Subject: Re: null pthread_t X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2003 09:37:56 -0000 Daniel Eischen wrote: > This doesn't work where pthread_t's are integer id's (perhaps > used as indices into a lookup table to find the real pointer). > An index of 0 may be a valid thread id (which is why I assume > it was set to -1 in Linux). > > Unless you are advocating defining PTHREAD_NULL differently > depending on the threads implementation... But the code > should be rewritten to use a different method of validating > the thread (use a flag, or encapsulate it in an application > defined type along with a flag). I forgot to add the cast-value. And, no... it's definitely the wrong way to do things; if you need something like this,it's *much* better to use a covariable that's type invariant, e.g. "int started_thread_flag = 0;". And even -1 isn't safe; it might be a valid negative index. 8-). -- Terry From owner-freebsd-threads@FreeBSD.ORG Fri Jul 11 07:08: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 5552237B401 for ; Fri, 11 Jul 2003 07:08:57 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C52E43FAF for ; Fri, 11 Jul 2003 07:08:56 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h6BE8twV020170 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 11 Jul 2003 10:08:55 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h6BE8ol31689; Fri, 11 Jul 2003 10:08:50 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16142.50418.692392.183187@grasshopper.cs.duke.edu> Date: Fri, 11 Jul 2003 10:08:50 -0400 (EDT) To: freebsd-threads@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: dumb KSE question X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2003 14:08:57 -0000 We have a driver which will block a thread in a cv_timewait_sig() after it calls into driver via an ioctl. Under libc_r, this will naturally block the entire process until the driver wakes it up via a cv_signal(). I assume that with KSE, the UTS will schedule another thread to run as a result of calling the cv_timewait_sig()? Ie, it won't block the entire process? Thanks, Drew From owner-freebsd-threads@FreeBSD.ORG Fri Jul 11 07:24:30 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 4F63537B401 for ; Fri, 11 Jul 2003 07:24:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 783BB43FBD for ; Fri, 11 Jul 2003 07:24:29 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h6BEONAI004689; Fri, 11 Jul 2003 10:24:23 -0400 (EDT) Date: Fri, 11 Jul 2003 10:24:23 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Andrew Gallatin In-Reply-To: <16142.50418.692392.183187@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question 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: Fri, 11 Jul 2003 14:24:30 -0000 There's no such thing as a dumb question... On Fri, 11 Jul 2003, Andrew Gallatin wrote: > > We have a driver which will block a thread in a cv_timewait_sig() > after it calls into driver via an ioctl. Under libc_r, this will > naturally block the entire process until the driver wakes it up via a > cv_signal(). > > I assume that with KSE, the UTS will schedule another thread to run as > a result of calling the cv_timewait_sig()? Ie, it won't block the > entire process? That's a dumb question :-) All joking aside, it is suppose to make a callback into the UTS so another thread can run and shouldn't block the process. It will be automatic and your driver does not need to do anything special. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jul 11 07:34: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 E064637B401; Fri, 11 Jul 2003 07:34:44 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F68C43F85; Fri, 11 Jul 2003 07:34:42 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h6BEYfwV021959 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Jul 2003 10:34:41 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h6BEYad31717; Fri, 11 Jul 2003 10:34:36 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16142.51964.387258.760328@grasshopper.cs.duke.edu> Date: Fri, 11 Jul 2003 10:34:36 -0400 (EDT) To: deischen@freebsd.org In-Reply-To: References: <16142.50418.692392.183187@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2003 14:34:45 -0000 Daniel Eischen writes: > That's a dumb question :-) All joking aside, it is suppose > to make a callback into the UTS so another thread can run > and shouldn't block the process. It will be automatic > and your driver does not need to do anything special. Thanks.. I just wanted to make sure that was really how it worked, and there was no exception hidden in the fine print for blocking done via ioctl rather than a normal syscall. Thanks! Drew From owner-freebsd-threads@FreeBSD.ORG Fri Jul 11 10:14:15 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 B490A37B401 for ; Fri, 11 Jul 2003 10:14:15 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 486EF43F75 for ; Fri, 11 Jul 2003 10:14:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc13) with ESMTP id <20030711171414015007bopde>; Fri, 11 Jul 2003 17:14:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA49968; Fri, 11 Jul 2003 10:14:11 -0700 (PDT) Date: Fri, 11 Jul 2003 10:14:11 -0700 (PDT) From: Julian Elischer To: Andrew Gallatin In-Reply-To: <16142.50418.692392.183187@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2003 17:14:16 -0000 On Fri, 11 Jul 2003, Andrew Gallatin wrote: > > We have a driver which will block a thread in a cv_timewait_sig() > after it calls into driver via an ioctl. Under libc_r, this will > naturally block the entire process until the driver wakes it up via a > cv_signal(). > > I assume that with KSE, the UTS will schedule another thread to run as > a result of calling the cv_timewait_sig()? Ie, it won't block the > entire process? yes, both libthr and libkse will allow your process to continue, sans thread. > > Thanks, > > Drew > > _______________________________________________ > 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 Jul 12 00:01: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 6CA2B37B401 for ; Sat, 12 Jul 2003 00:01:12 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63A7443FAF for ; Sat, 12 Jul 2003 00:01:11 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h6C70rsL066376; Sat, 12 Jul 2003 10:00:55 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F0FB225.50207@he.iki.fi> Date: Sat, 12 Jul 2003 10:00:53 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Andrew Gallatin cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question 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, 12 Jul 2003 07:01:12 -0000 Julian Elischer wrote: >On Fri, 11 Jul 2003, Andrew Gallatin wrote: > > > >>We have a driver which will block a thread in a cv_timewait_sig() >>after it calls into driver via an ioctl. Under libc_r, this will >>naturally block the entire process until the driver wakes it up via a >>cv_signal(). >> >>I assume that with KSE, the UTS will schedule another thread to run as >>a result of calling the cv_timewait_sig()? Ie, it won't block the >>entire process? >> >> > >yes, both libthr and libkse will allow your process to continue, sans >thread. > > > Would this also work with netgraph? Say an userland process waiting for "go ahead" signal at an ioctl in netgraph node (no data transfer neccessary)? How expensive in relative terms is cv_signal? Should I moderate calls to it if the above works fine othervise? In most cases the wait list would be empty, so the question more or less is if I should have a separate indication of somebody waiting for the condition or if the infrastructure of cv_* is optimized enough to do that for me. I would probably be calling cv_signal every time going out from interrupt context in the driver receiving packets. Pete From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 10:04:46 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 153DA37B401 for ; Sat, 12 Jul 2003 10:04:46 -0700 (PDT) Received: from h00609772adf0.ne.client2.attbi.com (h00609772adf0.ne.client2.attbi.com [66.31.45.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D38B43F85 for ; Sat, 12 Jul 2003 10:04:45 -0700 (PDT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1])h6CH5rrx001483 for ; Sat, 12 Jul 2003 13:05:53 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)h6CH5rNw001481 for freebsd-threads@freebsd.org; Sat, 12 Jul 2003 13:05:53 -0400 (EDT) Date: Sat, 12 Jul 2003 13:05:52 -0400 From: Craig Rodrigues To: freebsd-threads@freebsd.org Message-ID: <20030712170552.GA644@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: Remove _THREAD_SAFE from Makefiles? 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, 12 Jul 2003 17:04:46 -0000 Hi, According to this PR, _THREAD_SAFE has been remove from /usr/include/*.h http://www.freebsd.org/cgi/query-pr.cgi?pr=36167 So, can it be removed from the following places? Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libc_r/Makefile,v retrieving revision 1.35 diff -u -u -r1.35 Makefile --- Makefile 2 Jul 2003 13:27:54 -0000 1.35 +++ Makefile 12 Jul 2003 16:54:53 -0000 @@ -9,7 +9,7 @@ # system call stubs. LIB=c_r SHLIB_MAJOR= 5 -CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE +CFLAGS+=-DPTHREAD_KERNEL CFLAGS+=-I${.CURDIR}/../libc/include -I${.CURDIR}/uthread \ -I${.CURDIR}/../../include Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libthr/Makefile,v retrieving revision 1.5 diff -u -u -r1.5 Makefile --- Makefile 1 Jul 2003 15:07:01 -0000 1.5 +++ Makefile 12 Jul 2003 16:55:03 -0000 @@ -10,7 +10,7 @@ LIB=thr SHLIB_MAJOR= 1 DEBUG_FLAGS=-g -CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE +CFLAGS+=-DPTHREAD_KERNEL CFLAGS+=-I${.CURDIR}/../libc/include -I${.CURDIR}/thread \ -I${.CURDIR}/../../include -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 11:59:35 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 1E56A37B401 for ; Sat, 12 Jul 2003 11:59:35 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6503A43FBD for ; Sat, 12 Jul 2003 11:59:34 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h6CIxVAI011944; Sat, 12 Jul 2003 14:59:31 -0400 (EDT) Date: Sat, 12 Jul 2003 14:59:31 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Craig Rodrigues In-Reply-To: <20030712170552.GA644@crodrigues.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Remove _THREAD_SAFE from Makefiles? 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, 12 Jul 2003 18:59:35 -0000 On Sat, 12 Jul 2003, Craig Rodrigues wrote: > Hi, > > According to this PR, _THREAD_SAFE has been remove from /usr/include/*.h > > http://www.freebsd.org/cgi/query-pr.cgi?pr=36167 > > > So, can it be removed from the following places? Speaking for libc_r, yes please. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 12:27: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 E7C5137B401 for ; Sat, 12 Jul 2003 12:27:11 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C8643FEA for ; Sat, 12 Jul 2003 12:27:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc13) with ESMTP id <200307121927110150077rh6e>; Sat, 12 Jul 2003 19:27:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA59531; Sat, 12 Jul 2003 12:27:10 -0700 (PDT) Date: Sat, 12 Jul 2003 12:27:08 -0700 (PDT) From: Julian Elischer To: Petri Helenius In-Reply-To: <3F0FB225.50207@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Andrew Gallatin cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question 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, 12 Jul 2003 19:27:12 -0000 On Sat, 12 Jul 2003, Petri Helenius wrote: > Julian Elischer wrote: > > >On Fri, 11 Jul 2003, Andrew Gallatin wrote: > > > > > > > >>We have a driver which will block a thread in a cv_timewait_sig() > >>after it calls into driver via an ioctl. Under libc_r, this will > >>naturally block the entire process until the driver wakes it up via a > >>cv_signal(). > >> > >>I assume that with KSE, the UTS will schedule another thread to run as > >>a result of calling the cv_timewait_sig()? Ie, it won't block the > >>entire process? > >> > >> > > > >yes, both libthr and libkse will allow your process to continue, sans > >thread. > > > > > > > Would this also work with netgraph? Say an userland process waiting for > "go ahead" signal at an ioctl in netgraph node (no data transfer > neccessary)? ANY thread that blocks in ANY WAY will cause the spawning of a new thread to do more work. Assuming that the ioctl blocks. netgraph doesn; impliment ioctls so I don't see how this si a netgraph question, unless the netgraph node is CALLING code that blocks.. (which would be a no-no) > > How expensive in relative terms is cv_signal? Should I moderate calls to > it if the above works fine othervise? In most cases the wait list would > be empty, so the question more or less is if I should have a separate > indication Userland cv stuff is relatively cheap in linkse. A bit more expensive in libthr but still cheap. > of somebody waiting for the condition or if the infrastructure of cv_* is > optimized enough to do that for me. I would probably be calling cv_signal > every time going out from interrupt context in the driver receiving > packets. Are you talking anout kernel or userland CVs? I need more info to understand the question.. > > Pete > > > From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 12:42:08 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 4B26E37B405 for ; Sat, 12 Jul 2003 12:42:08 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id E241343FE0 for ; Sat, 12 Jul 2003 12:42:01 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h6CJfssL070831; Sat, 12 Jul 2003 22:41:54 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <003501c348ad$a599fba0$812a40c1@PETEX31> From: "Petri Helenius" To: "Julian Elischer" References: Date: Sat, 12 Jul 2003 22:41:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: Andrew Gallatin cc: freebsd-threads@freebsd.org Subject: Re: dumb KSE question 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, 12 Jul 2003 19:42:08 -0000 > Assuming that the ioctl blocks. > netgraph doesn; impliment ioctls so I don't see how I have a device which talks netgraph (similar to ng_device) so ioctlŽs are available across the device. > this si a netgraph question, unless the netgraph node is CALLING > code that blocks.. > (which would be a no-no) The cv IŽm talking about would be signaled by a device driver which shares some memory with the netgraph device node and the question is about if in the ng_device like thing I can have the d_ioctl_t block on the cv. > > > > > How expensive in relative terms is cv_signal? Should I moderate calls to > > it if the above works fine othervise? In most cases the wait list would > > be empty, so the question more or less is if I should have a separate > > indication > > Userland cv stuff is relatively cheap in linkse. A bit more expensive in > libthr but still cheap. How about in kernel. I suppose I cannot share cvŽs between kernel and userland so I need to cross into kernel to wait on a kernel cv? > > Are you talking anout kernel or userland CVs? > I need more info to understand the question.. > In this case kernel but I the information on userland is useful too. Pete From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 12:47:46 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 BBA7E37B401 for ; Sat, 12 Jul 2003 12:47:46 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB90543FDD for ; Sat, 12 Jul 2003 12:47:45 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h6CJkqsL070844; Sat, 12 Jul 2003 22:46:54 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <004d01c348ae$583084f0$812a40c1@PETEX31> From: "Petri Helenius" To: "Chris Knight" , "'Kai Mosebach'" , References: <007601c3467b$5f20e960$020aa8c0@aims.private> Date: Sat, 12 Jul 2003 22:46:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: LinuxThreads replacement 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, 12 Jul 2003 19:47:47 -0000 > get up to speed with thread implementations. Is it just me, or > are threads just a complete evil, which very few people > understand correctly and are able to implement and/or use them > correctly? > Threads are harder to understand and debug. Once you get to think in threads it actually helps productivity and creates simpler programs because you can create a thread for a task instead of going trough dozens of condition statements every time you return from a select or similar. Other such advantages exist. Also, since future CPUs and systems are likely to have more parallel execution units, threaded programs are ready to take advantage of such beasts if your memory coherency protocol does not eat up your performance. Pete From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 12:51:28 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 2467D37B404; Sat, 12 Jul 2003 12:51:28 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3F0643F85; Sat, 12 Jul 2003 12:51:26 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h6CJpPsL070889; Sat, 12 Jul 2003 22:51:25 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <005501c348ae$f9ff8dd0$812a40c1@PETEX31> From: "Petri Helenius" To: "Mike Makonnen" References: <001b01c3463a$0f907a00$0100a8c0@alpha> <006401c3464d$de848a00$812a40c1@PETEX31> <20030710001204.GB10504@kokeb.ambesa.net> Date: Sat, 12 Jul 2003 22:51:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-performance@freebsd.org cc: Kai Mosebach cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement 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, 12 Jul 2003 19:51:28 -0000 > > It's not as simple as that. In practice a lot of factors about > your system and the type of work you're doing will affect the > performance. On paper, the SA/KSE method is supposed to combine > the best aspects of 1:1 (libthr) and N:1 (libc_r), and should > threoretically be "better" than either one. But, in practice, > complexity and overhead may drown out the performance gains. > Conversely, context switching overhead may not be as great a > penalty for the 1:1 model on modern cpus. > Anyone have any numbers of different architechtures for the context switch? AMD64? Itanium? i386? PPC? Sparc? How about interrupt latency? SMP coherency overhead? The basic memory bandwidth has become a marketing thing so the raw megabytes per second are readily available but in multiprocessor and multithreaded environment there is a lot more into it. Pete From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 15:27:29 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 9A0EE37B401; Sat, 12 Jul 2003 15:27:29 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48BD743F75; Sat, 12 Jul 2003 15:27:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6CMRTUp021550; Sat, 12 Jul 2003 15:27:29 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6CMRRoA021546; Sat, 12 Jul 2003 15:27:27 -0700 (PDT) Date: Sat, 12 Jul 2003 15:27:27 -0700 (PDT) From: Kris Kennaway Message-Id: <200307122227.h6CMRRoA021546@freefall.freebsd.org> To: root@shandritokkel.homeunix.org, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, threads@FreeBSD.org Subject: Re: bin/50733: buildworld won't build, because of linking problem 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, 12 Jul 2003 22:27:29 -0000 Synopsis: buildworld won't build, because of linking problem State-Changed-From-To: feedback->analyzed State-Changed-By: kris State-Changed-When: Sat Jul 12 15:25:46 PDT 2003 State-Changed-Why: Building world with optimization greater than -O1 is unsupported, but the information in the audit trail seems to identify a specific problem that might be possible to fix. Responsible-Changed-From-To: freebsd-bugs->threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 15:25:46 PDT 2003 Responsible-Changed-Why: Building world with optimization greater than -O1 is unsupported, but the information in the audit trail seems to identify a specific problem that might be possible to fix. http://www.freebsd.org/cgi/query-pr.cgi?pr=50733 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:32:17 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA2037B401; Sat, 12 Jul 2003 18:32:17 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7C643FA3; Sat, 12 Jul 2003 18:32:17 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1WHUp052521; Sat, 12 Jul 2003 18:32:17 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1WHPB052517; Sat, 12 Jul 2003 18:32:17 -0700 (PDT) Date: Sat, 12 Jul 2003 18:32:17 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130132.h6D1WHPB052517@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/35622: sigaltstack is missing in libc_r 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, 13 Jul 2003 01:32:18 -0000 Synopsis: sigaltstack is missing in libc_r Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:32:06 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=35622 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:32:45 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09EB137B401; Sat, 12 Jul 2003 18:32:45 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9847543F93; Sat, 12 Jul 2003 18:32:44 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1WiUp052587; Sat, 12 Jul 2003 18:32:44 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1WixH052583; Sat, 12 Jul 2003 18:32:44 -0700 (PDT) Date: Sat, 12 Jul 2003 18:32:44 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130132.h6D1WixH052583@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/20861: libc_r does not honor socket timeouts 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, 13 Jul 2003 01:32:45 -0000 Synopsis: libc_r does not honor socket timeouts Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:32:35 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=20861 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:32:59 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66AE937B401; Sat, 12 Jul 2003 18:32:59 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E9243F93; Sat, 12 Jul 2003 18:32:59 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1WwUp052635; Sat, 12 Jul 2003 18:32:58 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1Wwek052631; Sat, 12 Jul 2003 18:32:58 -0700 (PDT) Date: Sat, 12 Jul 2003 18:32:58 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130132.h6D1Wwek052631@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/24472: libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket options 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, 13 Jul 2003 01:32:59 -0000 Synopsis: libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket options Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:32:49 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=24472 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:33:19 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B214F37B404; Sat, 12 Jul 2003 18:33:19 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D17343F3F; Sat, 12 Jul 2003 18:33:19 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1XJUp052683; Sat, 12 Jul 2003 18:33:19 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1XJhC052679; Sat, 12 Jul 2003 18:33:19 -0700 (PDT) Date: Sat, 12 Jul 2003 18:33:19 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130133.h6D1XJhC052679@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/24632: libc_r delicate deviation from libc in handling SIGCHLD 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, 13 Jul 2003 01:33:20 -0000 Synopsis: libc_r delicate deviation from libc in handling SIGCHLD Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:33:06 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=24632 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:33:35 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A32737B401; Sat, 12 Jul 2003 18:33:35 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D56DF43FB1; Sat, 12 Jul 2003 18:33:34 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1XYUp052731; Sat, 12 Jul 2003 18:33:34 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1XYbe052727; Sat, 12 Jul 2003 18:33:34 -0700 (PDT) Date: Sat, 12 Jul 2003 18:33:34 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130133.h6D1XYbe052727@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/26307: libc_r aborts when using the KDE media player (noatun) with the sound server(aRts) 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, 13 Jul 2003 01:33:35 -0000 X-List-Received-Date: Sun, 13 Jul 2003 01:33:35 -0000 Synopsis: libc_r aborts when using the KDE media player (noatun) with the sound server(aRts) Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:33:26 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=26307 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:33:55 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9108B37B401; Sat, 12 Jul 2003 18:33:55 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D13DB43FAF; Sat, 12 Jul 2003 18:33:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1XsUp052779; Sat, 12 Jul 2003 18:33:54 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1Xs3O052775; Sat, 12 Jul 2003 18:33:54 -0700 (PDT) Date: Sat, 12 Jul 2003 18:33:54 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130133.h6D1Xs3O052775@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/35329: Linking against libc_r.* provokes nasty linker messages about unsafe functions 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, 13 Jul 2003 01:33:55 -0000 Synopsis: Linking against libc_r.* provokes nasty linker messages about unsafe functions Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:33:42 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=35329 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:34:46 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B53437B401; Sat, 12 Jul 2003 18:34:46 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF1E43FA3; Sat, 12 Jul 2003 18:34:45 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1YjUp052832; Sat, 12 Jul 2003 18:34:45 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1Yj2D052828; Sat, 12 Jul 2003 18:34:45 -0700 (PDT) Date: Sat, 12 Jul 2003 18:34:45 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130134.h6D1Yj2D052828@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/49087: Signals lost in programs linked with libc_r 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, 13 Jul 2003 01:34:46 -0000 Synopsis: Signals lost in programs linked with libc_r Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:34:37 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=49087 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:35:07 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30F2D37B401; Sat, 12 Jul 2003 18:35:07 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFD8043F75; Sat, 12 Jul 2003 18:35:06 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1Z6Up052885; Sat, 12 Jul 2003 18:35:06 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1Z6FR052881; Sat, 12 Jul 2003 18:35:06 -0700 (PDT) Date: Sat, 12 Jul 2003 18:35:06 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130135.h6D1Z6FR052881@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/37676: libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wrappers 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, 13 Jul 2003 01:35:07 -0000 Synopsis: libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wrappers Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:34:54 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=37676 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:35:48 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F9FB37B401; Sat, 12 Jul 2003 18:35:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBE9943F93; Sat, 12 Jul 2003 18:35:47 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1ZlUp052945; Sat, 12 Jul 2003 18:35:47 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1ZlLK052941; Sat, 12 Jul 2003 18:35:47 -0700 (PDT) Date: Sat, 12 Jul 2003 18:35:47 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130135.h6D1ZlLK052941@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/19247: uthread_sigaction.c does not do anything wrt SA_NOCLDWAIT 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, 13 Jul 2003 01:35:48 -0000 Synopsis: uthread_sigaction.c does not do anything wrt SA_NOCLDWAIT Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:35:26 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=19247 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:36:00 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF73937B401; Sat, 12 Jul 2003 18:36:00 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F29243F3F; Sat, 12 Jul 2003 18:36:00 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1a0Up052993; Sat, 12 Jul 2003 18:36:00 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1a0IS052989; Sat, 12 Jul 2003 18:36:00 -0700 (PDT) Date: Sat, 12 Jul 2003 18:36:00 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130136.h6D1a0IS052989@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/33951: pthread_cancel is ignored 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, 13 Jul 2003 01:36:01 -0000 Synopsis: pthread_cancel is ignored Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:35:51 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=33951 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:36:13 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77DBA37B414; Sat, 12 Jul 2003 18:36:13 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 103BD43F75; Sat, 12 Jul 2003 18:36:13 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1aCUp053041; Sat, 12 Jul 2003 18:36:12 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1aCAQ053037; Sat, 12 Jul 2003 18:36:12 -0700 (PDT) Date: Sat, 12 Jul 2003 18:36:12 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130136.h6D1aCAQ053037@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/20016: pthreads: Cannot set scheduling timer/Cannot set virtual timer 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, 13 Jul 2003 01:36:14 -0000 Synopsis: pthreads: Cannot set scheduling timer/Cannot set virtual timer Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:36:05 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=20016 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:36:36 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D988637B404; Sat, 12 Jul 2003 18:36:36 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 767AD43FBF; Sat, 12 Jul 2003 18:36:36 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1aaUp053107; Sat, 12 Jul 2003 18:36:36 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1aaCN053103; Sat, 12 Jul 2003 18:36:36 -0700 (PDT) Date: Sat, 12 Jul 2003 18:36:36 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130136.h6D1aaCN053103@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/24641: pthread_rwlock_rdlock can deadlock 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, 13 Jul 2003 01:36:37 -0000 Synopsis: pthread_rwlock_rdlock can deadlock Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:36:26 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=24641 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:36:55 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2FC637B404; Sat, 12 Jul 2003 18:36:54 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D6C143FB1; Sat, 12 Jul 2003 18:36:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1asUp053160; Sat, 12 Jul 2003 18:36:54 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1asuR053156; Sat, 12 Jul 2003 18:36:54 -0700 (PDT) Date: Sat, 12 Jul 2003 18:36:54 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130136.h6D1asuR053156@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext 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, 13 Jul 2003 01:36:55 -0000 Synopsis: pthread_kill signal handler doesn't get sigcontext or ucontext Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:36:45 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=31661 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:37:08 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 352AE37B401; Sat, 12 Jul 2003 18:37:08 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C71A643FB1; Sat, 12 Jul 2003 18:37:07 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1b7Up053208; Sat, 12 Jul 2003 18:37:07 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1b7Ss053204; Sat, 12 Jul 2003 18:37:07 -0700 (PDT) Date: Sat, 12 Jul 2003 18:37:07 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130137.h6D1b7Ss053204@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/32295: pthread dont dequeue signals X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2003 01:37:08 -0000 Synopsis: pthread dont dequeue signals Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:37:00 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=32295 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:37:29 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 867D137B401; Sat, 12 Jul 2003 18:37:29 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2173F43F85; Sat, 12 Jul 2003 18:37:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1bTUp053265; Sat, 12 Jul 2003 18:37:29 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1bSFU053261; Sat, 12 Jul 2003 18:37:29 -0700 (PDT) Date: Sat, 12 Jul 2003 18:37:29 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130137.h6D1bSFU053261@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/33723: select(2) implementation in threaded (-lc_r) library is incorrect 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, 13 Jul 2003 01:37:29 -0000 X-List-Received-Date: Sun, 13 Jul 2003 01:37:29 -0000 Synopsis: select(2) implementation in threaded (-lc_r) library is incorrect Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:37:21 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=33723 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:37:47 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DD8037B40F; Sat, 12 Jul 2003 18:37:47 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0414D43FBF; Sat, 12 Jul 2003 18:37:47 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1bkUp053316; Sat, 12 Jul 2003 18:37:46 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1bkGe053309; Sat, 12 Jul 2003 18:37:46 -0700 (PDT) Date: Sat, 12 Jul 2003 18:37:46 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130137.h6D1bkGe053309@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/38549: the procces compiled whith pthread stopped in pthread_poll if system date change to lower date 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, 13 Jul 2003 01:37:47 -0000 Synopsis: the procces compiled whith pthread stopped in pthread_poll if system date change to lower date Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:37:39 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=38549 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:38:15 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 345BD37B401; Sat, 12 Jul 2003 18:38:15 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C00F843F85; Sat, 12 Jul 2003 18:38:14 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1cEUp053371; Sat, 12 Jul 2003 18:38:14 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1cEMc053367; Sat, 12 Jul 2003 18:38:14 -0700 (PDT) Date: Sat, 12 Jul 2003 18:38:14 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130138.h6D1cEMc053367@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/39922: [PATCH?] Threaded applications executed with closed std file descr. could not use redirections 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, 13 Jul 2003 01:38:15 -0000 Synopsis: [PATCH?] Threaded applications executed with closed std file descr. could not use redirections Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:38:03 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=39922 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:39:05 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1777F37B401; Sat, 12 Jul 2003 18:39:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A235743F93; Sat, 12 Jul 2003 18:39:04 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1d4Up053467; Sat, 12 Jul 2003 18:39:04 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1d4hV053463; Sat, 12 Jul 2003 18:39:04 -0700 (PDT) Date: Sat, 12 Jul 2003 18:39:04 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130139.h6D1d4hV053463@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/41331: Pthread library open sets O_NONBLOCK flag and causes unnecessary EAGAIN errors especially with /dev/stdout. 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, 13 Jul 2003 01:39:05 -0000 Synopsis: Pthread library open sets O_NONBLOCK flag and causes unnecessary EAGAIN errors especially with /dev/stdout. Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:38:58 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=41331 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:39:16 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE5E037B401; Sat, 12 Jul 2003 18:39:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BBCF43FB1; Sat, 12 Jul 2003 18:39:16 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1dGUp053515; Sat, 12 Jul 2003 18:39:16 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1dG4q053511; Sat, 12 Jul 2003 18:39:16 -0700 (PDT) Date: Sat, 12 Jul 2003 18:39:16 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130139.h6D1dG4q053511@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex 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, 13 Jul 2003 01:39:17 -0000 Synopsis: abnormal CPU useage when use pthread_mutex Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:39:10 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=43887 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:39:27 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3042A37B401; Sat, 12 Jul 2003 18:39:27 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA20C43F3F; Sat, 12 Jul 2003 18:39:26 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1dQUp053563; Sat, 12 Jul 2003 18:39:26 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1dQYv053559; Sat, 12 Jul 2003 18:39:26 -0700 (PDT) Date: Sat, 12 Jul 2003 18:39:26 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130139.h6D1dQYv053559@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/48856: Setting SIGCHLD to SIG_IGN still leaves zombies under 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, 13 Jul 2003 01:39:27 -0000 Synopsis: Setting SIGCHLD to SIG_IGN still leaves zombies under threads Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:39:21 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=48856 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:39:38 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5144137B401; Sat, 12 Jul 2003 18:39:38 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C4B43FDF; Sat, 12 Jul 2003 18:39:37 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1dbUp053611; Sat, 12 Jul 2003 18:39:37 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1db96053607; Sat, 12 Jul 2003 18:39:37 -0700 (PDT) Date: Sat, 12 Jul 2003 18:39:37 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130139.h6D1db96053607@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/51949: thread in accept cannot be cancelled 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, 13 Jul 2003 01:39:38 -0000 Synopsis: thread in accept cannot be cancelled Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:39:32 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=51949 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:39:49 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E700B37B401; Sat, 12 Jul 2003 18:39:49 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8320C43FBF; Sat, 12 Jul 2003 18:39:49 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1dnUp053659; Sat, 12 Jul 2003 18:39:49 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1dnuN053655; Sat, 12 Jul 2003 18:39:49 -0700 (PDT) Date: Sat, 12 Jul 2003 18:39:49 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130139.h6D1dnuN053655@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/52817: top(1) shows garbage for threaded processes 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, 13 Jul 2003 01:39:50 -0000 X-List-Received-Date: Sun, 13 Jul 2003 01:39:50 -0000 Synopsis: top(1) shows garbage for threaded processes Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:39:44 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=52817 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:40:10 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5238E37B401; Sat, 12 Jul 2003 18:40:10 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E40FF43FA3; Sat, 12 Jul 2003 18:40:09 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1e9Up053729; Sat, 12 Jul 2003 18:40:09 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1e9wR053725; Sat, 12 Jul 2003 18:40:09 -0700 (PDT) Date: Sat, 12 Jul 2003 18:40:09 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130140.h6D1e9wR053725@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/18824: gethostbyname is not thread safe 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, 13 Jul 2003 01:40:10 -0000 Synopsis: gethostbyname is not thread safe Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:40:03 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=18824 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:40:28 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D83A37B401; Sat, 12 Jul 2003 18:40:28 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D09143FBD; Sat, 12 Jul 2003 18:40:28 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1eSUp053971; Sat, 12 Jul 2003 18:40:28 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1eRKE053967; Sat, 12 Jul 2003 18:40:27 -0700 (PDT) Date: Sat, 12 Jul 2003 18:40:27 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130140.h6D1eRKE053967@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/22190: A threaded read(2) from a socketpair(2) fd can sometimes fail with errno 19 (ENODEV) 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, 13 Jul 2003 01:40:29 -0000 Synopsis: A threaded read(2) from a socketpair(2) fd can sometimes fail with errno 19 (ENODEV) Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:40:15 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=22190 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:40:42 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFCCC37B401; Sat, 12 Jul 2003 18:40:42 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5783043F3F; Sat, 12 Jul 2003 18:40:42 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1egUp054055; Sat, 12 Jul 2003 18:40:42 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1egoI054051; Sat, 12 Jul 2003 18:40:42 -0700 (PDT) Date: Sat, 12 Jul 2003 18:40:42 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130140.h6D1egoI054051@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/30464: pthread mutex attributes -- pshared 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, 13 Jul 2003 01:40:43 -0000 Synopsis: pthread mutex attributes -- pshared Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:40:34 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=30464 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:41:00 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAFA637B401; Sat, 12 Jul 2003 18:40:59 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7756A43F75; Sat, 12 Jul 2003 18:40:59 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1exUp054196; Sat, 12 Jul 2003 18:40:59 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1ex9E054192; Sat, 12 Jul 2003 18:40:59 -0700 (PDT) Date: Sat, 12 Jul 2003 18:40:59 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130140.h6D1ex9E054192@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/40671: pthread_cancel doesn't remove thread from condition queue 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, 13 Jul 2003 01:41:00 -0000 Synopsis: pthread_cancel doesn't remove thread from condition queue Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:40:53 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=40671 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 18:41:23 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0389D37B401; Sat, 12 Jul 2003 18:41:22 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9210943F3F; Sat, 12 Jul 2003 18:41:22 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D1fMUp054297; Sat, 12 Jul 2003 18:41:22 -0700 (PDT) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D1fMoZ054293; Sat, 12 Jul 2003 18:41:22 -0700 (PDT) Date: Sat, 12 Jul 2003 18:41:22 -0700 (PDT) From: Kris Kennaway Message-Id: <200307130141.h6D1fMoZ054293@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: i386/34536: accept() blocks other 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, 13 Jul 2003 01:41:23 -0000 Synopsis: accept() blocks other threads Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Sat Jul 12 18:41:17 PDT 2003 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=34536 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 22:48:29 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6024737B401; Sat, 12 Jul 2003 22:48:29 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFF2C43F85; Sat, 12 Jul 2003 22:48:28 -0700 (PDT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D5mSUp089482; Sat, 12 Jul 2003 22:48:28 -0700 (PDT) (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D5mSEV089478; Sat, 12 Jul 2003 22:48:28 -0700 (PDT) Date: Sat, 12 Jul 2003 22:48:28 -0700 (PDT) From: Daniel Eischen Message-Id: <200307130548.h6D5mSEV089478@freefall.freebsd.org> To: ports@geeksrus.net, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/35329: Linking against libc_r.* provokes nasty linker messages about unsafe functions 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, 13 Jul 2003 05:48:29 -0000 Synopsis: Linking against libc_r.* provokes nasty linker messages about unsafe functions State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Sat Jul 12 22:47:23 PDT 2003 State-Changed-Why: User error. In 4.x, you can't link to libc_r with -lc_r; you need to use -pthread (so libc isn't included in the link!) http://www.freebsd.org/cgi/query-pr.cgi?pr=35329 From owner-freebsd-threads@FreeBSD.ORG Sat Jul 12 22:56:05 2003 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E52E237B401; Sat, 12 Jul 2003 22:56:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E62043F85; Sat, 12 Jul 2003 22:56:05 -0700 (PDT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h6D5u5Up090044; Sat, 12 Jul 2003 22:56:05 -0700 (PDT) (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h6D5u5Zu090040; Sat, 12 Jul 2003 22:56:05 -0700 (PDT) Date: Sat, 12 Jul 2003 22:56:05 -0700 (PDT) From: Daniel Eischen Message-Id: <200307130556.h6D5u5Zu090040@freefall.freebsd.org> To: archer@whichever.org, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: misc/33723: select(2) implementation in threaded (-lc_r) library is incorrect 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, 13 Jul 2003 05:56:06 -0000 Synopsis: select(2) implementation in threaded (-lc_r) library is incorrect State-Changed-From-To: patched->closed State-Changed-By: deischen State-Changed-When: Sat Jul 12 22:55:24 PDT 2003 State-Changed-Why: Fix was commited over 1 year ago. http://www.freebsd.org/cgi/query-pr.cgi?pr=33723