From owner-freebsd-threads@FreeBSD.ORG Mon Feb 14 11:02:00 2005 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 EB86616A501 for ; Mon, 14 Feb 2005 11:01:59 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8D8643D1F for ; Mon, 14 Feb 2005 11:01:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1EB1xm8015246 for ; Mon, 14 Feb 2005 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1EB1xhK015240 for freebsd-threads@freebsd.org; Mon, 14 Feb 2005 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 14 Feb 2005 11:01:59 GMT Message-Id: <200502141101.j1EB1xhK015240@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 11:02:00 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/04/22] threads/65883threads libkse's sigwait does not work after fork o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc o [2003/05/08] threads/51949threads thread in accept cannot be cancelled s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/09/14] threads/71725threads Mysql Crashes frequently giving Sock Erro o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/11/25] threads/74370threads Cannot get lwp 0 registers in gdb o [2004/12/08] threads/74856threads dig/host broken w/ libthr o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/04] threads/75795threads applications linked with -lc_r can't clos o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function 25 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/01/20] threads/76513threads libpthread is not working o [2005/01/29] threads/76821threads Add access to gdb unique thread id o [2005/02/01] threads/76938threads include/unistd.h: ttyname_r prototype mis 12 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Feb 15 11:40:57 2005 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 B648616A4CE for ; Tue, 15 Feb 2005 11:40:57 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CC6743D45 for ; Tue, 15 Feb 2005 11:40:57 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.44 (FreeBSD)) id 1D114g-000CNS-Bj for freebsd-threads@FreeBSD.org; Tue, 15 Feb 2005 12:41:02 +0100 Date: Tue, 15 Feb 2005 12:41:02 +0100 From: Kirill Ponomarew To: freebsd-threads@FreeBSD.org Message-ID: <20050215114102.GA46454@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Subject: threads error 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, 15 Feb 2005 11:40:57 -0000 Starting threaded software compiled with -pthread on new -current failed with: Fatal error 'Thread has returned from _thread_switch' at line 1101 in file /usr/src/lib/libpthread/thread/thr_kern.c (errno = 0) [1] + abort (core dumped) /home/krion/mx/greylist -p inet:3336 Any tips ? -Kirill From owner-freebsd-threads@FreeBSD.ORG Tue Feb 15 14:04:19 2005 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 6692E16A4CE for ; Tue, 15 Feb 2005 14:04:19 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C06343D4C; Tue, 15 Feb 2005 14:04:19 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1FE4EY8079336; Tue, 15 Feb 2005 14:04:17 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4212015A.3020300@freebsd.org> Date: Tue, 15 Feb 2005 22:04:10 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kirill Ponomarew References: <20050215114102.GA46454@voodoo.oberon.net> In-Reply-To: <20050215114102.GA46454@voodoo.oberon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: threads error 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, 15 Feb 2005 14:04:19 -0000 Are you using statically linked library ? Kirill Ponomarew wrote: >Starting threaded software compiled with -pthread on new -current >failed with: > >Fatal error 'Thread has returned from _thread_switch' at line 1101 >in file /usr/src/lib/libpthread/thread/thr_kern.c (errno = 0) > >[1] + abort (core dumped) >/home/krion/mx/greylist -p inet:3336 > >Any tips ? > >-Kirill >_______________________________________________ >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 Feb 15 14:19:37 2005 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 0AC6116A4CE; Tue, 15 Feb 2005 14:19:37 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id B73CF43D45; Tue, 15 Feb 2005 14:19:36 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.44 (FreeBSD)) id 1D13Y2-0000kh-Ih; Tue, 15 Feb 2005 15:19:30 +0100 Date: Tue, 15 Feb 2005 15:19:30 +0100 From: Kirill Ponomarew To: David Xu Message-ID: <20050215141930.GB2428@voodoo.oberon.net> References: <20050215114102.GA46454@voodoo.oberon.net> <4212015A.3020300@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4212015A.3020300@freebsd.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: freebsd-threads@freebsd.org Subject: Re: threads error 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, 15 Feb 2005 14:19:37 -0000 On Tue, Feb 15, 2005 at 10:04:10PM +0800, David Xu wrote: > Are you using statically linked library ? Nope, it's dynamically linked. See also: http://www.freebsd.org/cgi/getmsg.cgi?fetch=349079+0+current/freebsd-current -Kirill From owner-freebsd-threads@FreeBSD.ORG Wed Feb 16 23:06:46 2005 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 254EE16A4CE for ; Wed, 16 Feb 2005 23:06:46 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id F226B43D41 for ; Wed, 16 Feb 2005 23:06:45 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id B5041CC6DA; Wed, 16 Feb 2005 15:06:45 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23307-05; Wed, 16 Feb 2005 15:06:44 -0800 (PST) Received: from [192.168.102.100] (c-67-168-93-230.client.comcast.net [67.168.93.230]) by mail.trippynames.com (Postfix) with ESMTP id 5BA50B47CA; Wed, 16 Feb 2005 15:06:44 -0800 (PST) In-Reply-To: <20050211001252.GY1060@sean.gigave.com> References: <20050211001252.GY1060@sean.gigave.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Wed, 16 Feb 2005 15:06:43 -0800 To: Sean Chittenden X-Mailer: Apple Mail (2.619.2) cc: threads@FreeBSD.org Subject: Re: Strange backtrace from amd64 + mysqld... 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, 16 Feb 2005 23:06:46 -0000 > Howdy. I'm running into a strange issue with MySQL 4.1.9 wherein its > eating itself every 24hrs. I grabbed a back trace, but haven't > recompiled MySQL with debugging given the strangeness of the backtrace > (can't tell if this is gdb or if the call stack is massively corrupt > due to some error). Given I've watched this repeat itself a few times > now and it seems to be dying in a pthread call, I'm posting here. > MySQL is the only process having problems, but it's also the most > heavily threaded and is getting pounded pretty hard. Without going > back to MySQL (esp given the backtrace), I want to verify that this > isn't a pthreads issue. Can someone comment on whether or not they've > seen this before? Out of desperation, I recompiled MySQL with system scoped threads instead of process scoped threads and MySQL has been running as well as MySQL runs. Seems as though there's some locking issue that gets exposed with process scoped threads vs. system scoped threads. Regardless, for those dropping in, MySQL should be used with system scoped threads if you're experiencing any abnormal MySQL instability (I'm also not sure if this is an amd64 specific issue or not). -sc -- Sean Chittenden From owner-freebsd-threads@FreeBSD.ORG Thu Feb 17 15:15:05 2005 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 748A716A4CE for ; Thu, 17 Feb 2005 15:15:05 +0000 (GMT) Received: from relay.rdsnet.ro (gimli.rdsnet.ro [193.231.236.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 2E8F143D4C for ; Thu, 17 Feb 2005 15:15:04 +0000 (GMT) (envelope-from itetcu@people.tecnik93.com) Received: (qmail 9033 invoked from network); 17 Feb 2005 15:10:12 -0000 Received: from unknown (HELO smtp.rdsnet.ro) (62.231.74.130) by smtp1-133.rdsnet.ro with SMTP; 17 Feb 2005 15:10:12 -0000 Received: (qmail 29270 invoked by uid 89); 17 Feb 2005 15:19:10 -0000 Received: from unknown (HELO buh.cameradicommercio.ro) (82.76.1.117) by 0 with SMTP; 17 Feb 2005 15:19:10 -0000 Received: from it.buh.cameradicommercio.ro (it.buh.cameradicommercio.ro [192.168.0.10]) by buh.cameradicommercio.ro (Postfix) with ESMTP id D8F7F6161; Thu, 17 Feb 2005 17:14:58 +0200 (EET) Received: from it.buh.cameradicommercio.ro (localhost.buh.tecnik93.com [127.0.0.1]) by it.buh.cameradicommercio.ro (Postfix) with ESMTP id 04E13111; Thu, 17 Feb 2005 17:14:57 +0200 (EET) Date: Thu, 17 Feb 2005 17:14:56 +0200 From: Ion-Mihai Tetcu To: Sean Chittenden Message-ID: <20050217171456.4b3c4db5@it.buh.cameradicommercio.ro> In-Reply-To: <20050211001252.GY1060@sean.gigave.com> References: <20050211001252.GY1060@sean.gigave.com> X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: threads@FreeBSD.org Subject: Re: Strange backtrace from amd64 + mysqld... 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, 17 Feb 2005 15:15:05 -0000 On Thu, 10 Feb 2005 16:12:52 -0800 Sean Chittenden wrote: > Howdy. I'm running into a strange issue with MySQL 4.1.9 wherein its > eating itself every 24hrs. [ ... ] > What really bothers me about this, is if I restart mysqld by hand (ie, > not from mysqld_safe), the database comes up and behaves correctly for > ~24hrs before it starts to puke again. When it does, it cores every > few minutes until I bounce it by hand. In the meantime, because it's > dumping out core files, the system becomes reasonably unusable. > Thoughts, or is this there some coincidental behavior going on? > > FreeBSD host.example.com 5.3-STABLE FreeBSD 5.3-STABLE #1: Mon Feb 7 17:35:07 PST 2005 root@host.example.com:/usr/obj/usr/src/sys/CONFIG amd64 I have problems with mail/dspam-devel on amd64 and only if I run it in daemon mode (stand-alone it doesn't use threads). It doesn't crash, just spans the threads and stay there. I can say if it's the app or the system. If someone could tell me what tool to use (valgrind works only on i386) I'd be glad to debug further. The system is a 5.3-REALEASE and MySQL is 4.1.9 compiled (for now) with defaults, MyIsam tables (tried inodb but it was way to slow) and had no mysql problems so far. -- IOnut Unregistered ;) FreeBSD "user" From owner-freebsd-threads@FreeBSD.ORG Thu Feb 17 16:23:23 2005 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 7DD0C16A4CE for ; Thu, 17 Feb 2005 16:23:23 +0000 (GMT) Received: from mx.highway.ne.jp (pip7.usen.ad.jp [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5044743D31 for ; Thu, 17 Feb 2005 16:23:22 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1D1oQy-0004be-Sg for threads@FreeBSD.org; Fri, 18 Feb 2005 01:23:20 +0900 Message-ID: <4214C4D5.2080100@highway.ne.jp> Date: Fri, 18 Feb 2005 01:22:45 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: threads@FreeBSD.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: thread accounting in libpthread 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, 17 Feb 2005 16:23:23 -0000 Hi, thr_accounting function (libpthread/thread/thr_kern.c) calculates thread->slice_usec, and it uses tm_uticks, tm_sticks and _clock_res_usec. I think that kernel counts up tm_uticks and tm_sticks at statclock interrupt time, and on -CURRENT _clock_res_usec is 1000 and on 5-STABLE it is 10000. Does thr_accounting calculate thread->slice_usec correctly? -------------------- Kazuaki Oda From owner-freebsd-threads@FreeBSD.ORG Thu Feb 17 20:51:06 2005 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 64B3016A4CE for ; Thu, 17 Feb 2005 20:51:06 +0000 (GMT) Received: from gigave.com (mail.gigave.com [38.113.228.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39DA743D54 for ; Thu, 17 Feb 2005 20:51:06 +0000 (GMT) (envelope-from sean@sean.gigave.com) Received: from sean.gigave.com [38.113.228.242](9y9eg58l122ukuc0)by gigave.comwith esmtp(Exim 4.43 #1 (Gentoo Linux))id 1D1shX-0006QE-Vo; Thu, 17 Feb 2005 12:56:43 -0800 Received: by sean.gigave.com (Postfix, from userid 1001) id 0FF47116FC; Thu, 17 Feb 2005 12:51:06 -0800 (PST) Date: Thu, 17 Feb 2005 12:51:06 -0800 From: Sean Chittenden To: Ion-Mihai Tetcu Message-ID: <20050217205106.GD60630@sean.gigave.com> References: <20050211001252.GY1060@sean.gigave.com> <20050217171456.4b3c4db5@it.buh.cameradicommercio.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050217171456.4b3c4db5@it.buh.cameradicommercio.ro> User-Agent: Mutt/1.5.6i cc: threads@FreeBSD.org Subject: Re: Strange backtrace from amd64 + mysqld... 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, 17 Feb 2005 20:51:06 -0000 > I have problems with mail/dspam-devel on amd64 and only if I run it in > daemon mode (stand-alone it doesn't use threads). It doesn't crash, just > spans the threads and stay there. I can say if it's the app or the > system. > If someone could tell me what tool to use (valgrind works only on i386) > I'd be glad to debug further. > > The system is a 5.3-REALEASE and MySQL is 4.1.9 compiled (for now) with > defaults, MyIsam tables (tried inodb but it was way to slow) and had no > mysql problems so far. Try setting the process up to use libthr instead of libpthreads via libmap.conf(5). If that fixes your problems, it's a good bet there's some kind of synchronization issue on amd64 that you're running into. -sc -- Sean Chittenden From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 07:11:27 2005 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 A210C16A4CE for ; Fri, 18 Feb 2005 07:11:27 +0000 (GMT) Received: from fth-smtp01.covansys.com (cbschgex01.cbsinc.com [12.162.224.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1538143D3F for ; Fri, 18 Feb 2005 07:11:27 +0000 (GMT) (envelope-from GKumar7@covansys.com) Received: from fth-ex02.covansys.com ([10.3.82.20]) by fth-smtp01.covansys.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Feb 2005 02:11:27 -0500 Received: from chn-ex04.CVNS.corp.covansys.com ([10.6.4.60]) by fth-ex02.covansys.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Feb 2005 02:11:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Feb 2005 12:41:10 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: semaphores and multithreading Thread-Index: AcUViQLI+kjPC0zQRK6HAh66giuItQ== From: "KUMAR Gyan Raj" To: X-OriginalArrivalTime: 18 Feb 2005 07:11:25.0796 (UTC) FILETIME=[0F198240:01C51589] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: semaphores and multithreading 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, 18 Feb 2005 07:11:27 -0000 Hi, Could you tell me how we can lock the file using the thread? Pls anybody can help me? With warm regards, gyan Confidentiality Statement: This message is intended only for the individual or entity to which it is= addressed. It may contain privileged, confidential information which is = exempt from disclosure under applicable laws. If you are not the intended= recipient, please note that you are strictly prohibited from disseminati= ng or distributing this information (other than to the intended recipient= ) or copying this information. If you have received this communication in= error, please notify us immediately by return email. From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 16:10:01 2005 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 8917E16A4CE for ; Fri, 18 Feb 2005 16:10:01 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1152043D41 for ; Fri, 18 Feb 2005 16:10:01 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1IG9u7G022727; Fri, 18 Feb 2005 11:09:57 -0500 (EST) Date: Fri, 18 Feb 2005 11:09:56 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kazuaki Oda In-Reply-To: <4214C4D5.2080100@highway.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: thread accounting in libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 16:10:01 -0000 On Fri, 18 Feb 2005, Kazuaki Oda wrote: > Hi, > > thr_accounting function (libpthread/thread/thr_kern.c) calculates > thread->slice_usec, and it uses tm_uticks, tm_sticks and _clock_res_usec. > I think that kernel counts up tm_uticks and tm_sticks at statclock interrupt > time, and on -CURRENT _clock_res_usec is 1000 and on 5-STABLE it is 10000. > > Does thr_accounting calculate thread->slice_usec correctly? I just fixed this. It didn't really affect anything, though, since it's all relative. You could have used any bogus number for the resolution of a tick. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 16:56:05 2005 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 2076816A4CE; Fri, 18 Feb 2005 16:56:05 +0000 (GMT) Received: from mx.highway.ne.jp (pip8.usen.ad.jp [61.122.117.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17F4D43D1F; Fri, 18 Feb 2005 16:56:04 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop11.isp.us-com.jp with esmtp (Mail 4.20) id 1D2BQ9-0004zt-JF; Sat, 19 Feb 2005 01:56:01 +0900 Message-ID: <42161DFE.70701@highway.ne.jp> Date: Sat, 19 Feb 2005 01:55:26 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en 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: threads@freebsd.org Subject: Re: thread accounting in libpthread 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, 18 Feb 2005 16:56:05 -0000 Daniel Eischen wrote: >On Fri, 18 Feb 2005, Kazuaki Oda wrote: > > > >>Hi, >> >>thr_accounting function (libpthread/thread/thr_kern.c) calculates >>thread->slice_usec, and it uses tm_uticks, tm_sticks and _clock_res_usec. >>I think that kernel counts up tm_uticks and tm_sticks at statclock interrupt >>time, and on -CURRENT _clock_res_usec is 1000 and on 5-STABLE it is 10000. >> >>Does thr_accounting calculate thread->slice_usec correctly? >> >> > >I just fixed this. It didn't really affect anything, though, since >it's all relative. You could have used any bogus number for the >resolution of a tick. > > > Thanks. And while looking at thr_kern.c, I've had one more question. In kse_switchout_thread, after calling thr_accounting thread is placed at the tail of run queue or at the head of it according to thread->slice_usec. But in kse_check_completed, thread is just placed at the tail of run queue. Is there any reason why thread is not placed at the head of run queue in case of thread->slice_usec != -1? -------------------- Kazuaki Oda From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 18:57:26 2005 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 0114116A4CE for ; Fri, 18 Feb 2005 18:57:26 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AD9A43D3F for ; Fri, 18 Feb 2005 18:57:25 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1IIvNGa004608; Fri, 18 Feb 2005 13:57:24 -0500 (EST) Date: Fri, 18 Feb 2005 13:57:23 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kazuaki Oda In-Reply-To: <42161DFE.70701@highway.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: thread accounting in libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 18:57:26 -0000 On Sat, 19 Feb 2005, Kazuaki Oda wrote: > > And while looking at thr_kern.c, I've had one more question. > In kse_switchout_thread, after calling thr_accounting thread is placed > at the tail of run queue or at the head of it according to > thread->slice_usec. > But in kse_check_completed, thread is just placed at the tail of run queue. > Is there any reason why thread is not placed at the head of run queue in > case of thread->slice_usec != -1? Because it already blocked and we don't want to needlessly switch out a currently running thread that hasn't used its quantum. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 20:40:21 2005 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 2794116A4CE for ; Fri, 18 Feb 2005 20:40:21 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE6A543D55 for ; Fri, 18 Feb 2005 20:40:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1IKeK4I019753 for ; Fri, 18 Feb 2005 20:40:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1IKeKG6019752; Fri, 18 Feb 2005 20:40:20 GMT (envelope-from gnats) Date: Fri, 18 Feb 2005 20:40:20 GMT Message-Id: <200502182040.j1IKeKG6019752@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Craig Rodrigues Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Rodrigues List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 20:40:21 -0000 The following reply was made to PR threads/76938; it has been noted by GNATS. From: Craig Rodrigues To: freebsd-gnats-submit@freebsd.org Cc: tmclaugh@sdf.lonestar.org, freebsd-standards@freebsd.org Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing Date: Fri, 18 Feb 2005 15:30:45 -0500 The following patch exports ttyname_r() from and makes it conform to the Single Unix Specification: http://www.opengroup.org/onlinepubs/009695399/functions/ttyname.html Can someone with a commit bit take a look at it? -- Craig Rodrigues rodrigc@crodrigues.org --- lib/libc/gen/ttyname.3.orig Thu Feb 17 17:10:20 2005 +++ lib/libc/gen/ttyname.3 Fri Feb 18 15:10:31 2005 @@ -37,6 +37,7 @@ .Os .Sh NAME .Nm ttyname , +.Nm ttyname_r , .Nm isatty , .Nm ttyslot .Nd get name of associated terminal (tty) from file descriptor @@ -47,6 +48,8 @@ .Ft char * .Fn ttyname "int fd" .Ft int +.Fn ttyname_r "int fd" "char *buf" "size_t bufsize" +.Ft int .Fn isatty "int fd" .Ft int .Fn ttyslot void @@ -80,7 +83,13 @@ gets the related device name of a file descriptor for which .Fn isatty -is true +is true. +.Pp +.Fn ttyname +returns the name stored in a static buffer which will be overwritten +on subsequent calls. +.Fn ttyname_r +takes a buffer and length as arguments to avoid this problem. .Pp The .Fn ttyslot @@ -98,12 +107,25 @@ a .Dv NULL pointer is returned. +The +.Fn ttyname_r +function returns 0 if successful. Otherwise an error number is returned. .Pp The .Fn ttyslot function returns the unit number of the device file if found; otherwise the value zero is returned. +.Sh ERRORS +.Fn ttyname_r +may return the following error codes: +.Bl -tag -width Er +.It Bq Er ENOTTY +.Fa fd +is not a valid file descriptor. +.It Bq Er ERANGE +.Fa bufsize +is smaller than the length of the string to be returned. .Sh FILES .Bl -tag -width /etc/ttys -compact .It Pa /dev/\(** @@ -121,11 +143,6 @@ function appeared in .At v7 . -.Sh BUGS -The -.Fn ttyname -function leaves its result in an internal static object and returns -a pointer to that object. -Subsequent calls to -.Fn ttyname -will modify the same object. +.Fn ttyname_r +appeared in +.Fx 6.0 . --- lib/libc/gen/ttyname.c.orig Thu Feb 17 17:14:32 2005 +++ lib/libc/gen/ttyname.c Fri Feb 18 15:20:09 2005 @@ -48,12 +48,13 @@ #include #include #include +#include #include "un-namespace.h" #include "libc_private.h" static char buf[sizeof(_PATH_DEV) + MAXNAMLEN]; -static char *ttyname_threaded(int fd); +static void ttyname_threaded(int fd, char **b); static char *ttyname_unthreaded(int fd); static pthread_mutex_t ttyname_lock = PTHREAD_MUTEX_INITIALIZER; @@ -68,45 +69,41 @@ if (__isthreaded == 0) ret = ttyname_unthreaded(fd); else - ret = ttyname_threaded(fd); + ttyname_threaded(fd, &ret); return (ret); } -char * +int ttyname_r(int fd, char *buf, size_t len) { struct stat sb; - char *rval; - - rval = NULL; /* Must be a terminal. */ if (!isatty(fd)) - return (rval); + return ENOTTY; /* Must be a character device. */ if (_fstat(fd, &sb) || !S_ISCHR(sb.st_mode)) - return (rval); + return ENOTTY; /* Must have enough room */ if (len <= sizeof(_PATH_DEV)) - return (rval); + return ERANGE; strcpy(buf, _PATH_DEV); devname_r(sb.st_rdev, S_IFCHR, - buf + strlen(buf), sizeof(buf) - strlen(buf)); - return (buf); + buf + strlen(buf), len - strlen(buf)); + return 0; } -static char * -ttyname_threaded(int fd) +static void +ttyname_threaded(int fd, char **b) { - char *buf; - if (ttyname_init == 0) { _pthread_mutex_lock(&ttyname_lock); if (ttyname_init == 0) { if (_pthread_key_create(&ttyname_key, free)) { _pthread_mutex_unlock(&ttyname_lock); - return (NULL); + *b = NULL; + return; } ttyname_init = 1; } @@ -114,17 +111,19 @@ } /* Must have thread specific data field to put data */ - if ((buf = _pthread_getspecific(ttyname_key)) == NULL) { - if ((buf = malloc(sizeof(_PATH_DEV) + MAXNAMLEN)) != NULL) { - if (_pthread_setspecific(ttyname_key, buf) != 0) { - free(buf); - return (NULL); + if ((*b = _pthread_getspecific(ttyname_key)) == NULL) { + if ((*b = malloc(sizeof(_PATH_DEV) + MAXNAMLEN)) != NULL) { + if (_pthread_setspecific(ttyname_key, *b) != 0) { + free(*b); + *b = NULL; + return; } } else { - return (NULL); + *b = NULL; + return; } } - return (ttyname_r(fd, buf, sizeof(_PATH_DEV) + MAXNAMLEN)); + ttyname_r(fd, *b, sizeof(_PATH_DEV) + MAXNAMLEN); } static char * --- include/unistd.h.orig Thu Feb 17 17:37:41 2005 +++ include/unistd.h Thu Feb 17 17:38:19 2005 @@ -365,6 +365,7 @@ pid_t tcgetpgrp(int); int tcsetpgrp(int, pid_t); char *ttyname(int); +int ttyname_r(int, char *, size_t); int unlink(const char *); ssize_t write(int, const void *, size_t); From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 20:51:11 2005 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 9854016A4CF for ; Fri, 18 Feb 2005 20:51:11 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30D7C43D1F for ; Fri, 18 Feb 2005 20:51:11 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1IKp8lN025926; Fri, 18 Feb 2005 15:51:09 -0500 (EST) Date: Fri, 18 Feb 2005 15:51:01 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Craig Rodrigues In-Reply-To: <200502182040.j1IKeKG6019752@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 20:51:11 -0000 On Fri, 18 Feb 2005, Craig Rodrigues wrote: > The following reply was made to PR threads/76938; it has been noted by GNATS. > > From: Craig Rodrigues > To: freebsd-gnats-submit@freebsd.org > Cc: tmclaugh@sdf.lonestar.org, freebsd-standards@freebsd.org > Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing > Date: Fri, 18 Feb 2005 15:30:45 -0500 > > The following patch exports ttyname_r() from and makes it > conform to the Single Unix Specification: > http://www.opengroup.org/onlinepubs/009695399/functions/ttyname.html > > Can someone with a commit bit take a look at it? Style: all returns should be "return (foo)", not "return foo". This may also cause an ABI change since ttyname_r use to return (char *). I'm not sure of the impact though 'cause it was never in a header file. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 21:18:22 2005 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 8732B16A4CE; Fri, 18 Feb 2005 21:18:22 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4D9D43D53; Fri, 18 Feb 2005 21:18:21 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (sccrmhc14) with ESMTP id <2005021821182001400s73ude>; Fri, 18 Feb 2005 21:18:21 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) j1ILI9iV012732; Fri, 18 Feb 2005 16:18:10 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)j1ILI9Ip012731; Fri, 18 Feb 2005 16:18:09 -0500 (EST) (envelope-from rodrigc) Date: Fri, 18 Feb 2005 16:18:08 -0500 From: Craig Rodrigues To: freebsd-gnats-submit@freebsd.org Message-ID: <20050218211808.GA12700@crodrigues.org> References: <200502182040.j1IKeKG6019752@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: tmclaugh@sdf.lonestar.org cc: freebsd-threads@freebsd.org Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing 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, 18 Feb 2005 21:18:22 -0000 On Fri, Feb 18, 2005 at 03:51:01PM -0500, Daniel Eischen wrote: > Style: all returns should be "return (foo)", not "return foo". OK, the attached patch fixes this. > This may also cause an ABI change since ttyname_r use to > return (char *). I'm not sure of the impact though 'cause > it was never in a header file. This does change the ABI, but I also don't know what the impact is, since this function was not exported from a header file. The old ttyname_r() should have been declared static, since it was never exported through a header file, but that's life. At least the new ttyname_r() conforms to SuS, so it has a better chance of working with software written on other platforms. -- Craig Rodrigues rodrigc@crodrigues.org --- lib/libc/gen/ttyname.3.orig Thu Feb 17 17:10:20 2005 +++ lib/libc/gen/ttyname.3 Fri Feb 18 15:10:31 2005 @@ -37,6 +37,7 @@ .Os .Sh NAME .Nm ttyname , +.Nm ttyname_r , .Nm isatty , .Nm ttyslot .Nd get name of associated terminal (tty) from file descriptor @@ -47,6 +48,8 @@ .Ft char * .Fn ttyname "int fd" .Ft int +.Fn ttyname_r "int fd" "char *buf" "size_t bufsize" +.Ft int .Fn isatty "int fd" .Ft int .Fn ttyslot void @@ -80,7 +83,13 @@ gets the related device name of a file descriptor for which .Fn isatty -is true +is true. +.Pp +.Fn ttyname +returns the name stored in a static buffer which will be overwritten +on subsequent calls. +.Fn ttyname_r +takes a buffer and length as arguments to avoid this problem. .Pp The .Fn ttyslot @@ -98,12 +107,25 @@ a .Dv NULL pointer is returned. +The +.Fn ttyname_r +function returns 0 if successful. Otherwise an error number is returned. .Pp The .Fn ttyslot function returns the unit number of the device file if found; otherwise the value zero is returned. +.Sh ERRORS +.Fn ttyname_r +may return the following error codes: +.Bl -tag -width Er +.It Bq Er ENOTTY +.Fa fd +is not a valid file descriptor. +.It Bq Er ERANGE +.Fa bufsize +is smaller than the length of the string to be returned. .Sh FILES .Bl -tag -width /etc/ttys -compact .It Pa /dev/\(** @@ -121,11 +143,6 @@ function appeared in .At v7 . -.Sh BUGS -The -.Fn ttyname -function leaves its result in an internal static object and returns -a pointer to that object. -Subsequent calls to -.Fn ttyname -will modify the same object. +.Fn ttyname_r +appeared in +.Fx 6.0 . --- lib/libc/gen/ttyname.c.orig Thu Feb 17 17:14:32 2005 +++ lib/libc/gen/ttyname.c Fri Feb 18 15:20:09 2005 @@ -48,12 +48,13 @@ #include #include #include +#include #include "un-namespace.h" #include "libc_private.h" static char buf[sizeof(_PATH_DEV) + MAXNAMLEN]; -static char *ttyname_threaded(int fd); +static void ttyname_threaded(int fd, char **b); static char *ttyname_unthreaded(int fd); static pthread_mutex_t ttyname_lock = PTHREAD_MUTEX_INITIALIZER; @@ -68,45 +69,41 @@ if (__isthreaded == 0) ret = ttyname_unthreaded(fd); else - ret = ttyname_threaded(fd); + ttyname_threaded(fd, &ret); return (ret); } -char * +int ttyname_r(int fd, char *buf, size_t len) { struct stat sb; - char *rval; - - rval = NULL; /* Must be a terminal. */ if (!isatty(fd)) - return (rval); + return (ENOTTY); /* Must be a character device. */ if (_fstat(fd, &sb) || !S_ISCHR(sb.st_mode)) - return (rval); + return (ENOTTY); /* Must have enough room */ if (len <= sizeof(_PATH_DEV)) - return (rval); + return (ERANGE); strcpy(buf, _PATH_DEV); devname_r(sb.st_rdev, S_IFCHR, - buf + strlen(buf), sizeof(buf) - strlen(buf)); - return (buf); + buf + strlen(buf), len - strlen(buf)); + return (0); } -static char * -ttyname_threaded(int fd) +static void +ttyname_threaded(int fd, char **b) { - char *buf; - if (ttyname_init == 0) { _pthread_mutex_lock(&ttyname_lock); if (ttyname_init == 0) { if (_pthread_key_create(&ttyname_key, free)) { _pthread_mutex_unlock(&ttyname_lock); - return (NULL); + *b = NULL; + return; } ttyname_init = 1; } @@ -114,17 +111,19 @@ } /* Must have thread specific data field to put data */ - if ((buf = _pthread_getspecific(ttyname_key)) == NULL) { - if ((buf = malloc(sizeof(_PATH_DEV) + MAXNAMLEN)) != NULL) { - if (_pthread_setspecific(ttyname_key, buf) != 0) { - free(buf); - return (NULL); + if ((*b = _pthread_getspecific(ttyname_key)) == NULL) { + if ((*b = malloc(sizeof(_PATH_DEV) + MAXNAMLEN)) != NULL) { + if (_pthread_setspecific(ttyname_key, *b) != 0) { + free(*b); + *b = NULL; + return; } } else { - return (NULL); + *b = NULL; + return; } } - return (ttyname_r(fd, buf, sizeof(_PATH_DEV) + MAXNAMLEN)); + ttyname_r(fd, *b, sizeof(_PATH_DEV) + MAXNAMLEN); } static char * --- include/unistd.h.orig Thu Feb 17 17:37:41 2005 +++ include/unistd.h Thu Feb 17 17:38:19 2005 @@ -365,6 +365,7 @@ pid_t tcgetpgrp(int); int tcsetpgrp(int, pid_t); char *ttyname(int); +int ttyname_r(int, char *, size_t); int unlink(const char *); ssize_t write(int, const void *, size_t); From owner-freebsd-threads@FreeBSD.ORG Fri Feb 18 21:20:29 2005 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 B556616A4D0 for ; Fri, 18 Feb 2005 21:20:29 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1612743D3F for ; Fri, 18 Feb 2005 21:20:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1ILKIbd025158 for ; Fri, 18 Feb 2005 21:20:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1ILKI0q025157; Fri, 18 Feb 2005 21:20:18 GMT (envelope-from gnats) Date: Fri, 18 Feb 2005 21:20:18 GMT Message-Id: <200502182120.j1ILKI0q025157@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Craig Rodrigues Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Rodrigues List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 21:20:29 -0000 The following reply was made to PR threads/76938; it has been noted by GNATS. From: Craig Rodrigues To: freebsd-gnats-submit@freebsd.org Cc: tmclaugh@sdf.lonestar.org, freebsd-threads@freebsd.org Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing Date: Fri, 18 Feb 2005 16:18:08 -0500 On Fri, Feb 18, 2005 at 03:51:01PM -0500, Daniel Eischen wrote: > Style: all returns should be "return (foo)", not "return foo". OK, the attached patch fixes this. > This may also cause an ABI change since ttyname_r use to > return (char *). I'm not sure of the impact though 'cause > it was never in a header file. This does change the ABI, but I also don't know what the impact is, since this function was not exported from a header file. The old ttyname_r() should have been declared static, since it was never exported through a header file, but that's life. At least the new ttyname_r() conforms to SuS, so it has a better chance of working with software written on other platforms. -- Craig Rodrigues rodrigc@crodrigues.org --- lib/libc/gen/ttyname.3.orig Thu Feb 17 17:10:20 2005 +++ lib/libc/gen/ttyname.3 Fri Feb 18 15:10:31 2005 @@ -37,6 +37,7 @@ .Os .Sh NAME .Nm ttyname , +.Nm ttyname_r , .Nm isatty , .Nm ttyslot .Nd get name of associated terminal (tty) from file descriptor @@ -47,6 +48,8 @@ .Ft char * .Fn ttyname "int fd" .Ft int +.Fn ttyname_r "int fd" "char *buf" "size_t bufsize" +.Ft int .Fn isatty "int fd" .Ft int .Fn ttyslot void @@ -80,7 +83,13 @@ gets the related device name of a file descriptor for which .Fn isatty -is true +is true. +.Pp +.Fn ttyname +returns the name stored in a static buffer which will be overwritten +on subsequent calls. +.Fn ttyname_r +takes a buffer and length as arguments to avoid this problem. .Pp The .Fn ttyslot @@ -98,12 +107,25 @@ a .Dv NULL pointer is returned. +The +.Fn ttyname_r +function returns 0 if successful. Otherwise an error number is returned. .Pp The .Fn ttyslot function returns the unit number of the device file if found; otherwise the value zero is returned. +.Sh ERRORS +.Fn ttyname_r +may return the following error codes: +.Bl -tag -width Er +.It Bq Er ENOTTY +.Fa fd +is not a valid file descriptor. +.It Bq Er ERANGE +.Fa bufsize +is smaller than the length of the string to be returned. .Sh FILES .Bl -tag -width /etc/ttys -compact .It Pa /dev/\(** @@ -121,11 +143,6 @@ function appeared in .At v7 . -.Sh BUGS -The -.Fn ttyname -function leaves its result in an internal static object and returns -a pointer to that object. -Subsequent calls to -.Fn ttyname -will modify the same object. +.Fn ttyname_r +appeared in +.Fx 6.0 . --- lib/libc/gen/ttyname.c.orig Thu Feb 17 17:14:32 2005 +++ lib/libc/gen/ttyname.c Fri Feb 18 15:20:09 2005 @@ -48,12 +48,13 @@ #include #include #include +#include #include "un-namespace.h" #include "libc_private.h" static char buf[sizeof(_PATH_DEV) + MAXNAMLEN]; -static char *ttyname_threaded(int fd); +static void ttyname_threaded(int fd, char **b); static char *ttyname_unthreaded(int fd); static pthread_mutex_t ttyname_lock = PTHREAD_MUTEX_INITIALIZER; @@ -68,45 +69,41 @@ if (__isthreaded == 0) ret = ttyname_unthreaded(fd); else - ret = ttyname_threaded(fd); + ttyname_threaded(fd, &ret); return (ret); } -char * +int ttyname_r(int fd, char *buf, size_t len) { struct stat sb; - char *rval; - - rval = NULL; /* Must be a terminal. */ if (!isatty(fd)) - return (rval); + return (ENOTTY); /* Must be a character device. */ if (_fstat(fd, &sb) || !S_ISCHR(sb.st_mode)) - return (rval); + return (ENOTTY); /* Must have enough room */ if (len <= sizeof(_PATH_DEV)) - return (rval); + return (ERANGE); strcpy(buf, _PATH_DEV); devname_r(sb.st_rdev, S_IFCHR, - buf + strlen(buf), sizeof(buf) - strlen(buf)); - return (buf); + buf + strlen(buf), len - strlen(buf)); + return (0); } -static char * -ttyname_threaded(int fd) +static void +ttyname_threaded(int fd, char **b) { - char *buf; - if (ttyname_init == 0) { _pthread_mutex_lock(&ttyname_lock); if (ttyname_init == 0) { if (_pthread_key_create(&ttyname_key, free)) { _pthread_mutex_unlock(&ttyname_lock); - return (NULL); + *b = NULL; + return; } ttyname_init = 1; } @@ -114,17 +111,19 @@ } /* Must have thread specific data field to put data */ - if ((buf = _pthread_getspecific(ttyname_key)) == NULL) { - if ((buf = malloc(sizeof(_PATH_DEV) + MAXNAMLEN)) != NULL) { - if (_pthread_setspecific(ttyname_key, buf) != 0) { - free(buf); - return (NULL); + if ((*b = _pthread_getspecific(ttyname_key)) == NULL) { + if ((*b = malloc(sizeof(_PATH_DEV) + MAXNAMLEN)) != NULL) { + if (_pthread_setspecific(ttyname_key, *b) != 0) { + free(*b); + *b = NULL; + return; } } else { - return (NULL); + *b = NULL; + return; } } - return (ttyname_r(fd, buf, sizeof(_PATH_DEV) + MAXNAMLEN)); + ttyname_r(fd, *b, sizeof(_PATH_DEV) + MAXNAMLEN); } static char * --- include/unistd.h.orig Thu Feb 17 17:37:41 2005 +++ include/unistd.h Thu Feb 17 17:38:19 2005 @@ -365,6 +365,7 @@ pid_t tcgetpgrp(int); int tcsetpgrp(int, pid_t); char *ttyname(int); +int ttyname_r(int, char *, size_t); int unlink(const char *); ssize_t write(int, const void *, size_t); From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 13:18:31 2005 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 41E4D16A4CE; Sat, 19 Feb 2005 13:18:31 +0000 (GMT) Received: from mx.highway.ne.jp (pip7.usen.ad.jp [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE82043D4C; Sat, 19 Feb 2005 13:18:29 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1D2UVA-0004A8-Ks; Sat, 19 Feb 2005 22:18:28 +0900 Message-ID: <42173C82.7040408@highway.ne.jp> Date: Sat, 19 Feb 2005 22:17:54 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------070804040805030500010306" cc: threads@freebsd.org Subject: Re: thread accounting in libpthread 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, 19 Feb 2005 13:18:31 -0000 This is a multi-part message in MIME format. --------------070804040805030500010306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Daniel Eischen wrote: >On Sat, 19 Feb 2005, Kazuaki Oda wrote: > > >>And while looking at thr_kern.c, I've had one more question. >>In kse_switchout_thread, after calling thr_accounting thread is placed >>at the tail of run queue or at the head of it according to >>thread->slice_usec. >>But in kse_check_completed, thread is just placed at the tail of run queue. >>Is there any reason why thread is not placed at the head of run queue in >>case of thread->slice_usec != -1? >> >> > >Because it already blocked and we don't want to needlessly >switch out a currently running thread that hasn't used its >quantum. > > > Blocked? I think that completed threads are *not* blocked and they are ready to run except for suspended. And, kse_check_completed could be called after calling kse_wait. In this case there is currently no running thread. The reason why I am researching libpthread is that the attached program shows -------------------- thread 00: 55666 thread 01: 1161 thread 02: 1112 thread 03: 1112 thread 04: 55494 -------------------- on xterm on my UP machine. This is a unexpected result. It seems to me that libpthread does unfair scheduling. But on SMP machine that program shows expected result and on console too... -------------------- Kazuaki Oda --------------070804040805030500010306 Content-Type: text/plain; name="thrdtest.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="thrdtest.c" #include #include #include #include #include #include #include #define NTHREADS 5 #define BUFSZ 128 void *func(void *arg); typedef struct { int id; } funcarg; int stop = 0; long counts[NTHREADS]; int main(void) { pthread_t tids[NTHREADS]; funcarg *arg; int rval; int i; for (i = 0; i < NTHREADS; i++) { if ((arg = malloc(sizeof(funcarg))) == NULL) err(1, "malloc"); arg->id = i; if ((rval = pthread_create(&tids[i], NULL, func, arg)) != 0) errc(1, rval, "pthread_create"); } sleep(10); stop = 1; for (i = 0; i < NTHREADS; i++) { if ((rval = pthread_join(tids[i], NULL)) != 0) errc(1, rval, "pthread_join"); } printf("--------------------\n"); for (i = 0; i < NTHREADS; i++) printf("thread %02d: %ld\n", i, counts[i]); printf("--------------------\n"); return 0; } void *func(void *arg) { char buf[BUFSZ]; int id; int n; id = ((funcarg *)arg)->id; free(arg); while (!stop) { counts[id]++; n = snprintf(buf, sizeof(buf), "thread %02d: countup\n", id); write(STDOUT_FILENO, buf, n); } return NULL; } --------------070804040805030500010306-- From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 13:34:11 2005 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 ECD2F16A4CE; Sat, 19 Feb 2005 13:34:11 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8C1143D2D; Sat, 19 Feb 2005 13:34:11 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 520F946B8E; Sat, 19 Feb 2005 08:34:11 -0500 (EST) Date: Sat, 19 Feb 2005 13:32:41 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Craig Rodrigues In-Reply-To: <20050218211808.GA12700@crodrigues.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: tmclaugh@sdf.lonestar.org cc: freebsd-gnats-submit@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing 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, 19 Feb 2005 13:34:12 -0000 On Fri, 18 Feb 2005, Craig Rodrigues wrote: > On Fri, Feb 18, 2005 at 03:51:01PM -0500, Daniel Eischen wrote: > > Style: all returns should be "return (foo)", not "return foo". > > OK, the attached patch fixes this. > > > This may also cause an ABI change since ttyname_r use to > > return (char *). I'm not sure of the impact though 'cause > > it was never in a header file. > > This does change the ABI, but I also don't know what the impact is, > since this function was not exported from a header file. > > The old ttyname_r() should have been declared static, since it was never > exported through a header file, but that's life. At least the new > ttyname_r() conforms to SuS, so it has a better chance of working with > software written on other platforms. You might want to ask Kris Kenneway if he could do a scan of the ports/packages to see what links against the ttyname_r symbol, if anything. Robert N M Watson From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 13:34:58 2005 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 6404916A4CE; Sat, 19 Feb 2005 13:34:58 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1933643D45; Sat, 19 Feb 2005 13:34:58 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1JDYoQ4003699; Sat, 19 Feb 2005 13:34:54 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42174126.5000006@freebsd.org> Date: Sat, 19 Feb 2005 21:37:42 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kazuaki Oda References: <42173C82.7040408@highway.ne.jp> In-Reply-To: <42173C82.7040408@highway.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org Subject: Re: thread accounting in libpthread 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, 19 Feb 2005 13:34:58 -0000 I have run your program, here is the result: ... thread 04: countup thread 00: countup thread 01: countup -------------------- thread 00: 553150 thread 01: 562367 thread 02: 553351 thread 03: 532770 thread 04: 542718 -------------------- It is fair scheduling. I run it under console and no other programs are eating CPU time, note that I didn't run it under X11 terminal. David Xu Kazuaki Oda wrote: > Daniel Eischen wrote: > >> On Sat, 19 Feb 2005, Kazuaki Oda wrote: >> >> >>> And while looking at thr_kern.c, I've had one more question. >>> In kse_switchout_thread, after calling thr_accounting thread is placed >>> at the tail of run queue or at the head of it according to >>> thread->slice_usec. >>> But in kse_check_completed, thread is just placed at the tail of run >>> queue. >>> Is there any reason why thread is not placed at the head of run >>> queue in >>> case of thread->slice_usec != -1? >>> >> >> >> Because it already blocked and we don't want to needlessly >> switch out a currently running thread that hasn't used its >> quantum. >> >> >> > > Blocked? I think that completed threads are *not* blocked and they > are ready > to run except for suspended. And, kse_check_completed could be called > after > calling kse_wait. In this case there is currently no running thread. > > The reason why I am researching libpthread is that the attached > program shows > -------------------- > thread 00: 55666 > thread 01: 1161 > thread 02: 1112 > thread 03: 1112 > thread 04: 55494 > -------------------- > on xterm on my UP machine. This is a unexpected result. It seems to > me that > libpthread does unfair scheduling. But on SMP machine that program shows > expected result and on console too... > > > -------------------- > Kazuaki Oda > >------------------------------------------------------------------------ > >#include >#include >#include >#include >#include >#include >#include > >#define NTHREADS 5 >#define BUFSZ 128 > >void *func(void *arg); > >typedef struct { > int id; >} funcarg; > >int stop = 0; >long counts[NTHREADS]; > >int main(void) >{ > pthread_t tids[NTHREADS]; > funcarg *arg; > int rval; > int i; > > for (i = 0; i < NTHREADS; i++) { > if ((arg = malloc(sizeof(funcarg))) == NULL) > err(1, "malloc"); > arg->id = i; > if ((rval = pthread_create(&tids[i], NULL, func, arg)) != 0) > errc(1, rval, "pthread_create"); > } > > sleep(10); > > stop = 1; > > for (i = 0; i < NTHREADS; i++) { > if ((rval = pthread_join(tids[i], NULL)) != 0) > errc(1, rval, "pthread_join"); > } > > printf("--------------------\n"); > for (i = 0; i < NTHREADS; i++) > printf("thread %02d: %ld\n", i, counts[i]); > printf("--------------------\n"); > > return 0; >} > >void *func(void *arg) >{ > char buf[BUFSZ]; > int id; > int n; > > id = ((funcarg *)arg)->id; > free(arg); > > while (!stop) { > counts[id]++; > n = snprintf(buf, sizeof(buf), "thread %02d: countup\n", id); > write(STDOUT_FILENO, buf, n); > } > > return NULL; >} > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Feb 19 13:35:18 2005 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 2393016A4CE for ; Sat, 19 Feb 2005 13:35:18 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC4FB43D2D for ; Sat, 19 Feb 2005 13:35:17 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 634BC46B91 for ; Sat, 19 Feb 2005 08:35:17 -0500 (EST) Date: Sat, 19 Feb 2005 13:33:47 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: threads@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: libpthread vs libthread, simply mysql benchmark (fwd) 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, 19 Feb 2005 13:35:18 -0000 FYI. Robert N M Watson ---------- Forwarded message ---------- Date: Sat, 19 Feb 2005 13:16:06 +0000 (GMT) From: Robert Watson To: performance@FreeBSD.org Subject: libpthread vs libthread, simply mysql benchmark In case it's of interest -- I occasionally run MySQL "supersmack" benchmarks at work on a dual Xeon box there. I ran the select benchmark on the box a few minutes ago, comparing libpthread and David Xu's new libthread on the box, and the results are pleasing: x 6-SMP-HTT-libpthread + 6-SMP-HTT-libthread +--------------------------------------------------------------------------+ | x + | | x ++ | | xxx +++ | |xxxxx +++ +| | |MA| |A| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 8300.25 8442.54 8379.03 8381.652 39.682672 + 10 10510.35 10646.98 10547.59 10551.599 39.893907 Difference at 95.0% confidence 2169.95 +/- 37.385 25.8893% +/- 0.446034% (Student's t, pooled s = 39.7884) In other words, a clear (and healthy) 26% performance improvement on this simple benchmark. I don't currently have other numbers to compare against, such as linuxthreads, etc. This is a 2.4GHz box with 1gb of memory running MySQL 4.0.23a. Typically, I get better performance without hyper-threading turned on, but I can't get into the BIOS of the box remotely so couldn't turn it off properly. I used the latest 6.x SMP kernel combined with the libthread drop from David's perforce branch. You can find a URL to his more recent code drops in the recent threads on freebsd-threads. FYI, here's a brief history of HTT performance over the past year as 5.x and 6.x matured: Version Transactions/sec 20040515-UP-4BSD 4862 20040515-SMP-4BSD 4620 20040515-SMP-ADMTX-4BSD 4846 20040615-UP-4BSD 4899 20040616-SMP-4BSD 4941 20040616-SMP-ADMTX-4BSD 4979 20040616-netperf-UP-giant-4BSD 4907 20040616-netperf-UP-mpsafe-4BSD 4939 20040616-netperf-SMP-giant-4BSD 4587 20040616-netperf-SMP-mpsafe-4BSD 4609 20040616-netperf-SMP-ADMTX-giant-4BSD 4662 20040616-netperf-SMP-ADMTX-mpsafe-4BSD 6425 20040713-netperf-SMP-ADMTX-mpsafe-4BSD 7063 20040717-netperf-SMP-ADMTX-mpsafe-4BSD 7118 As of today, I get about 8400tps with HTT turned on, probably a bit betterwith it turned off. By combining various factors we've introduced in the last couple of years, such as MPSAFE network stack, scheduling improvements, threading improvements, mutex changes, etc, we've improved performance on mysql by over 100% on SMP, going from quite sub-par performance in the depths of 5.x development (when all the infrastructure changes were going in but no optimizations) to quite healthy in 6.x, especially with the new threading library. Robert N M Watson _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 13:40:15 2005 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 80DFD16A4D3 for ; Sat, 19 Feb 2005 13:40:15 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6206A43D48 for ; Sat, 19 Feb 2005 13:40:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1JDeFNq003819 for ; Sat, 19 Feb 2005 13:40:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1JDeFP4003818; Sat, 19 Feb 2005 13:40:15 GMT (envelope-from gnats) Date: Sat, 19 Feb 2005 13:40:15 GMT Message-Id: <200502191340.j1JDeFP4003818@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Robert Watson Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Robert Watson List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2005 13:40:15 -0000 The following reply was made to PR threads/76938; it has been noted by GNATS. From: Robert Watson To: Craig Rodrigues Cc: freebsd-gnats-submit@freebsd.org, tmclaugh@sdf.lonestar.org, freebsd-threads@freebsd.org Subject: Re: threads/76938: include/unistd.h: ttyname_r prototype missing Date: Sat, 19 Feb 2005 13:32:41 +0000 (GMT) On Fri, 18 Feb 2005, Craig Rodrigues wrote: > On Fri, Feb 18, 2005 at 03:51:01PM -0500, Daniel Eischen wrote: > > Style: all returns should be "return (foo)", not "return foo". > > OK, the attached patch fixes this. > > > This may also cause an ABI change since ttyname_r use to > > return (char *). I'm not sure of the impact though 'cause > > it was never in a header file. > > This does change the ABI, but I also don't know what the impact is, > since this function was not exported from a header file. > > The old ttyname_r() should have been declared static, since it was never > exported through a header file, but that's life. At least the new > ttyname_r() conforms to SuS, so it has a better chance of working with > software written on other platforms. You might want to ask Kris Kenneway if he could do a scan of the ports/packages to see what links against the ttyname_r symbol, if anything. Robert N M Watson From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 13:44:48 2005 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 DEEB116A4CE; Sat, 19 Feb 2005 13:44:48 +0000 (GMT) Received: from mx.highway.ne.jp (pip7.usen.ad.jp [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DB3043D4C; Sat, 19 Feb 2005 13:44:48 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1D2Uuc-0007gT-SZ; Sat, 19 Feb 2005 22:44:47 +0900 Message-ID: <421742AC.9050509@highway.ne.jp> Date: Sat, 19 Feb 2005 22:44:12 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <42173C82.7040408@highway.ne.jp> <42174126.5000006@freebsd.org> In-Reply-To: <42174126.5000006@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org Subject: Re: thread accounting in libpthread 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, 19 Feb 2005 13:44:49 -0000 Yes. It is fair scheduling under console. My result is under xterm. Could you run it under xterm or any other x11 terminal? David Xu wrote: > I have run your program, here is the result: > > ... > thread 04: countup > thread 00: countup > thread 01: countup > -------------------- > thread 00: 553150 > thread 01: 562367 > thread 02: 553351 > thread 03: 532770 > thread 04: 542718 > -------------------- > > It is fair scheduling. I run it under console and no other programs > are eating CPU > time, note that I didn't run it under X11 terminal. > > David Xu > > Kazuaki Oda wrote: > >> Daniel Eischen wrote: >> >>> On Sat, 19 Feb 2005, Kazuaki Oda wrote: >>> >>> >>>> And while looking at thr_kern.c, I've had one more question. >>>> In kse_switchout_thread, after calling thr_accounting thread is placed >>>> at the tail of run queue or at the head of it according to >>>> thread->slice_usec. >>>> But in kse_check_completed, thread is just placed at the tail of >>>> run queue. >>>> Is there any reason why thread is not placed at the head of run >>>> queue in >>>> case of thread->slice_usec != -1? >>>> >>> >>> >>> >>> Because it already blocked and we don't want to needlessly >>> switch out a currently running thread that hasn't used its >>> quantum. >>> >>> >>> >> >> Blocked? I think that completed threads are *not* blocked and they >> are ready >> to run except for suspended. And, kse_check_completed could be >> called after >> calling kse_wait. In this case there is currently no running thread. >> >> The reason why I am researching libpthread is that the attached >> program shows >> -------------------- >> thread 00: 55666 >> thread 01: 1161 >> thread 02: 1112 >> thread 03: 1112 >> thread 04: 55494 >> -------------------- >> on xterm on my UP machine. This is a unexpected result. It seems to >> me that >> libpthread does unfair scheduling. But on SMP machine that program >> shows >> expected result and on console too... >> >> >> -------------------- >> Kazuaki Oda >> From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 13:52:33 2005 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 29D5916A4CE; Sat, 19 Feb 2005 13:52:33 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E10E643D2F; Sat, 19 Feb 2005 13:52:32 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1JDqPXZ004132; Sat, 19 Feb 2005 13:52:28 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42174545.7090404@freebsd.org> Date: Sat, 19 Feb 2005 21:55:17 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kazuaki Oda References: <42173C82.7040408@highway.ne.jp> <42174126.5000006@freebsd.org> <421742AC.9050509@highway.ne.jp> In-Reply-To: <421742AC.9050509@highway.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org Subject: Re: thread accounting in libpthread 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, 19 Feb 2005 13:52:33 -0000 Refreshed, I got it under x11: -------------------- thread 00: 25925 thread 01: 57635 thread 02: 24947 thread 03: 1187 thread 04: 13166 -------------------- the result seems a bit unfair. :) Kazuaki Oda wrote: > Yes. It is fair scheduling under console. My result is under xterm. > Could you run it under xterm or any other x11 terminal? > > > David Xu wrote: > >> I have run your program, here is the result: >> >> ... >> thread 04: countup >> thread 00: countup >> thread 01: countup >> -------------------- >> thread 00: 553150 >> thread 01: 562367 >> thread 02: 553351 >> thread 03: 532770 >> thread 04: 542718 >> -------------------- >> >> It is fair scheduling. I run it under console and no other programs >> are eating CPU >> time, note that I didn't run it under X11 terminal. >> >> David Xu >> >> Kazuaki Oda wrote: >> >>> Daniel Eischen wrote: >>> >>>> On Sat, 19 Feb 2005, Kazuaki Oda wrote: >>>> >>>> >>>>> And while looking at thr_kern.c, I've had one more question. >>>>> In kse_switchout_thread, after calling thr_accounting thread is >>>>> placed >>>>> at the tail of run queue or at the head of it according to >>>>> thread->slice_usec. >>>>> But in kse_check_completed, thread is just placed at the tail of >>>>> run queue. >>>>> Is there any reason why thread is not placed at the head of run >>>>> queue in >>>>> case of thread->slice_usec != -1? >>>>> >>>> >>>> >>>> >>>> >>>> Because it already blocked and we don't want to needlessly >>>> switch out a currently running thread that hasn't used its >>>> quantum. >>>> >>>> >>>> >>> >>> Blocked? I think that completed threads are *not* blocked and they >>> are ready >>> to run except for suspended. And, kse_check_completed could be >>> called after >>> calling kse_wait. In this case there is currently no running thread. >>> >>> The reason why I am researching libpthread is that the attached >>> program shows >>> -------------------- >>> thread 00: 55666 >>> thread 01: 1161 >>> thread 02: 1112 >>> thread 03: 1112 >>> thread 04: 55494 >>> -------------------- >>> on xterm on my UP machine. This is a unexpected result. It seems >>> to me that >>> libpthread does unfair scheduling. But on SMP machine that program >>> shows >>> expected result and on console too... >>> >>> >>> -------------------- >>> Kazuaki Oda >>> > > > From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 15:39:24 2005 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 E659016A4CE for ; Sat, 19 Feb 2005 15:39:24 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7124543D31 for ; Sat, 19 Feb 2005 15:39:24 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1JFdMuE008043; Sat, 19 Feb 2005 10:39:22 -0500 (EST) Date: Sat, 19 Feb 2005 10:39:21 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kazuaki Oda In-Reply-To: <42173C82.7040408@highway.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: thread accounting in libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2005 15:39:25 -0000 On Sat, 19 Feb 2005, Kazuaki Oda wrote: > Daniel Eischen wrote: > > >On Sat, 19 Feb 2005, Kazuaki Oda wrote: > > > >>And while looking at thr_kern.c, I've had one more question. > >>In kse_switchout_thread, after calling thr_accounting thread is placed > >>at the tail of run queue or at the head of it according to > >>thread->slice_usec. > >>But in kse_check_completed, thread is just placed at the tail of run queue. > >>Is there any reason why thread is not placed at the head of run queue in > >>case of thread->slice_usec != -1? > >> > >> > > > >Because it already blocked and we don't want to needlessly > >switch out a currently running thread that hasn't used its > >quantum. > > Blocked? I think that completed threads are *not* blocked and they are > ready Blocked is past tense above. It _had_ blocked in the kernel and that gave other threads a chance to run. You don't add it to the head of the queue because that makes it unfair to the other threads that were in the queue. The default scheduling is SCHED_RR in libpthread and that is laid out by POSIX. > to run except for suspended. And, kse_check_completed could be called after > calling kse_wait. In this case there is currently no running thread. kse_check_completed() is called after kse_wait(). Do you have local changes that removed it? -- DE From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 17:00:22 2005 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 7520E16A4CF; Sat, 19 Feb 2005 17:00:22 +0000 (GMT) Received: from mx.highway.ne.jp (pip7.usen.ad.jp [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84A9143D53; Sat, 19 Feb 2005 17:00:20 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1D2Xxp-0005hz-Sj; Sun, 20 Feb 2005 02:00:18 +0900 Message-ID: <4217707F.9050907@highway.ne.jp> Date: Sun, 20 Feb 2005 01:59:43 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en 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: threads@freebsd.org Subject: Re: thread accounting in libpthread 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, 19 Feb 2005 17:00:22 -0000 Daniel Eischen wrote: > On Sat, 19 Feb 2005, Kazuaki Oda wrote: > >> Daniel Eischen wrote: >> >> >On Sat, 19 Feb 2005, Kazuaki Oda wrote: >> > >> >>And while looking at thr_kern.c, I've had one more question. >> >>In kse_switchout_thread, after calling thr_accounting thread is placed >> >>at the tail of run queue or at the head of it according to >> >>thread->slice_usec. >> >>But in kse_check_completed, thread is just placed at the tail of >> run queue. >> >>Is there any reason why thread is not placed at the head of run >> queue in >> >>case of thread->slice_usec != -1? >> >> >> >> >> > >> >Because it already blocked and we don't want to needlessly >> >switch out a currently running thread that hasn't used its >> >quantum. >> >> Blocked? I think that completed threads are *not* blocked and they are >> ready > > > Blocked is past tense above. It _had_ blocked in the kernel > and that gave other threads a chance to run. You don't add > it to the head of the queue because that makes it unfair to > the other threads that were in the queue. The default > scheduling is SCHED_RR in libpthread and that is laid > out by POSIX. Sorry for my misreading. I've understood what you mean. > >> to run except for suspended. And, kse_check_completed could be >> called after >> calling kse_wait. In this case there is currently no running thread. > > > kse_check_completed() is called after kse_wait(). Do you > have local changes that removed it? > No, I have not changed. kse_check_completed() is called after kse_wait(). What I meant in the past e-mail was that in such case there was no running thread, and so we did not needlessly switch it out. Thanks. -------------------- Kazuaki Oda From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 19:20:51 2005 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 3A40B16A4CE for ; Sat, 19 Feb 2005 19:20:51 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE86F43D39 for ; Sat, 19 Feb 2005 19:20:50 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1JJKnUq005208; Sat, 19 Feb 2005 14:20:49 -0500 (EST) Date: Sat, 19 Feb 2005 14:20:49 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kazuaki Oda In-Reply-To: <4217707F.9050907@highway.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: thread accounting in libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2005 19:20:51 -0000 On Sun, 20 Feb 2005, Kazuaki Oda wrote: > Daniel Eischen wrote: > > > kse_check_completed() is called after kse_wait(). Do you > > have local changes that removed it? > > > > No, I have not changed. kse_check_completed() is called after kse_wait(). > What I meant in the past e-mail was that in such case there was no > running thread, > and so we did not needlessly switch it out. If there was no running thread before kse_wait(), then after kse_wait() returns and if there are completed threads, then either one thread completed or N threads completed. Either way, they are all added to the end of the run queue. But the run queue must have been empty to begin with, otherwise kse_wait() would not have been called. So it doesn't matter whether they are added to the head or the end of the queue. If one thread completes, then it will be run right away since it will be the only thread in the queue. If N threads complete (assuming they are all at the same priority) then the first thread pulled from the completed list will be run first since it will be the first thread added to the run queue. -- DE