From owner-freebsd-threads@FreeBSD.ORG Sun Jan 2 18:57: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 41C4C16A4CE for ; Sun, 2 Jan 2005 18:57:57 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1CD343D1D for ; Sun, 2 Jan 2005 18:57:53 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j02IviTl029769; Sun, 2 Jan 2005 20:57:45 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <41D84428.4070600@he.iki.fi> Date: Sun, 02 Jan 2005 20:57:44 +0200 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20041230024706.94879.qmail@web52401.mail.yahoo.com> <41D48C5D.5000906@elischer.org> In-Reply-To: <41D48C5D.5000906@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Thread time spikes 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, 02 Jan 2005 18:57:57 -0000 Julian Elischer wrote: > > try rtprio as well Does rtprio work with libpthread and are there caveats with adaptive mutexes? Pete From owner-freebsd-threads@FreeBSD.ORG Mon Jan 3 11:02:09 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 7641F16A4EF for ; Mon, 3 Jan 2005 11:02:09 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46E1D43D49 for ; Mon, 3 Jan 2005 11:02:09 +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 j03B29RB006243 for ; Mon, 3 Jan 2005 11:02:09 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j03B28bA006237 for freebsd-threads@freebsd.org; Mon, 3 Jan 2005 11:02:08 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 3 Jan 2005 11:02:08 GMT Message-Id: <200501031102.j03B28bA006237@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, 03 Jan 2005 11:02:09 -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 1 problem 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 23 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 9 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Jan 4 14:00:45 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 BF6B616A4CE for ; Tue, 4 Jan 2005 14:00:45 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86AFB43D46 for ; Tue, 4 Jan 2005 14:00:45 +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 j04E0jxD034339 for ; Tue, 4 Jan 2005 14:00:45 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j04E0jjp034332; Tue, 4 Jan 2005 14:00:45 GMT (envelope-from gnats) Resent-Date: Tue, 4 Jan 2005 14:00:45 GMT Resent-Message-Id: <200501041400.j04E0jjp034332@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Roman Nikitchenko Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14F5316A4CE for ; Tue, 4 Jan 2005 13:55:40 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D6C43D3F for ; Tue, 4 Jan 2005 13:55:40 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j04Dtdg3037602 for ; Tue, 4 Jan 2005 13:55:39 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j04DtdPf037598; Tue, 4 Jan 2005 13:55:39 GMT (envelope-from nobody) Message-Id: <200501041355.j04DtdPf037598@www.freebsd.org> Date: Tue, 4 Jan 2005 13:55:39 GMT From: Roman Nikitchenko To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: threads/75795: applications linked with -lc_r can't close() fd opened by kqueue(). 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, 04 Jan 2005 14:00:45 -0000 >Number: 75795 >Category: threads >Synopsis: applications linked with -lc_r can't close() fd opened by kqueue(). >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 04 14:00:45 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Roman Nikitchenko >Release: RELENG_5 >Organization: Trifle Co. Ltd. >Environment: FreeBSD hc.apex.dp.ua 5.3-STABLE FreeBSD 5.3-STABLE #0: Fri Dec 24 14:26:40 EET 2004 root@hc.apex.dp.ua:/usr/obj/usr/src/sys/HC i386 >Description: Any application that uses kqueue() can't close() obtained descriptors if linked with libc_r. It is FREEBSD-5.3 related problem. The errno is set to 6 (device not configured) after close. Applications which uses signals need to be linked against libc_r as KSE has some problems with signals (kse_thr_interrupt). >How-To-Repeat: Do "g++ -lc_r" for source like this: /* --- begin --- */ #include #include #include #include int main() { int poller = kqueue(); printf( "poller: %d\n", poller ); int r = close( poller ); if ( r<0 ) perror( "kqueue" ); } /* --- end --- */ >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Wed Jan 5 09:40:30 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 394BC16A4CE for ; Wed, 5 Jan 2005 09:40:30 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 227AA43D49 for ; Wed, 5 Jan 2005 09:40:30 +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 j059eUDn008759 for ; Wed, 5 Jan 2005 09:40:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j059eT9N008758; Wed, 5 Jan 2005 09:40:29 GMT (envelope-from gnats) Date: Wed, 5 Jan 2005 09:40:29 GMT Message-Id: <200501050940.j059eT9N008758@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Roman Nikitchenko Subject: Re: threads/75795: applications linked with -lc_r can't close() fd opened by kqueue(). X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Roman Nikitchenko List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 09:40:30 -0000 The following reply was made to PR threads/75795; it has been noted by GNATS. From: Roman Nikitchenko To: freebsd-gnats-submit@FreeBSD.org, roman@trifle.net Cc: Subject: Re: threads/75795: applications linked with -lc_r can't close() fd opened by kqueue(). Date: Wed, 05 Jan 2005 11:33:04 +0200 The reason was in unimplemented kqueue_stat() call (libc_r close() relays on fstat() ). Here is my own version (sys/kern/kern_event.c) i used to workaround problem: /*ARGSUSED*/ static int kqueue_stat(struct file *fp, struct stat *st, struct ucred *active_cred, struct thread *td) { struct kqueue *kq; int error; if ((error = kqueue_aquire(fp, &kq))) return ENOENT; KQ_LOCK(kq); bzero((void *)st, sizeof(*st)); st->st_size = kq->kq_count; kqueue_release(kq, 1); KQ_UNLOCK(kq); st->st_blksize = sizeof(struct kevent); st->st_mode = S_IFIFO; return (0); } Please check / apply this as soon as possible. Any binary transfered from 4.x system and using kevent() subsystem won't work until this will be done. Any application with kevent()'s linked against libc_r too. -- WBR, Roman Nikitchenko, http://smartgate.wtelecom.net _,,,_|\_/|_,,,_ From owner-freebsd-threads@FreeBSD.ORG Thu Jan 6 07:36:56 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 3522416A4CE for ; Thu, 6 Jan 2005 07:36:56 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id D411343D1D for ; Thu, 6 Jan 2005 07:36:54 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j067al3m071583 for ; Thu, 6 Jan 2005 09:36:48 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <41DCEA91.6040402@he.iki.fi> Date: Thu, 06 Jan 2005 09:36:49 +0200 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: higher speed mutexes 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, 06 Jan 2005 07:36:56 -0000 Hi, I have some low-contention mutexes which I'm trying to make perform better and I'm wondering if the current threading library does have some primitives I could use or if I'm better off using atomic_cmpset_* and pthread_yield() if the thread hit's contention (which should be about 1:10000 of the lock/unlock operation). Any scheduling caveats from above, except obviously it would spin while waiting for the lock. Most systems I plan on running this on have dual-hypethreading CPU's. I remember there were some discussion about dropping i386 compatible support for mutexes and using atomic operations instead. Is there code/compile time options for this on a branch I could check out and give it a spin? Pete From owner-freebsd-threads@FreeBSD.ORG Thu Jan 6 08:49:30 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 DDBAF16A4CE for ; Thu, 6 Jan 2005 08:49:30 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C476843D5E; Thu, 6 Jan 2005 08:49:30 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j068nMtU099661; Thu, 6 Jan 2005 08:49:24 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41DCFD2F.2040207@freebsd.org> Date: Thu, 06 Jan 2005 16:56:15 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Helenius References: <41DCEA91.6040402@he.iki.fi> In-Reply-To: <41DCEA91.6040402@he.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: higher speed mutexes 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, 06 Jan 2005 08:49:31 -0000 I will have low overhead pthread library available soon, for simple mutex, it is only an atomic_cmpset_long() plus a function call (pthread_mutex_lock) overhead. David Xu Petri Helenius wrote: > > Hi, > > I have some low-contention mutexes which I'm trying to make perform > better and I'm wondering if the current threading library does have some > primitives I could use or if I'm better off using atomic_cmpset_* and > pthread_yield() if the thread hit's contention (which should be about > 1:10000 of the lock/unlock operation). > > Any scheduling caveats from above, except obviously it would spin while > waiting for the lock. Most systems I plan on running this on have > dual-hypethreading CPU's. > > I remember there were some discussion about dropping i386 compatible > support for mutexes and using atomic operations instead. Is there > code/compile time options for this on a branch I could check out and > give it a spin? > > 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 Thu Jan 6 09:15: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 D88E516A4CE; Thu, 6 Jan 2005 09:15:58 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id E304643D60; Thu, 6 Jan 2005 09:15:57 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j069FuDt072343; Thu, 6 Jan 2005 11:15:56 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <41DD01CE.70004@he.iki.fi> Date: Thu, 06 Jan 2005 11:15:58 +0200 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org> In-Reply-To: <41DCFD2F.2040207@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: higher speed mutexes 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, 06 Jan 2005 09:15:59 -0000 David Xu wrote: > I will have low overhead pthread library available soon, for > simple mutex, it is only an atomic_cmpset_long() plus a function > call (pthread_mutex_lock) overhead. > Sounds great. Will this change the performance of rwlocks or is simple mutex preferred for performance sensitive applications? Is this something that I could drop on top of RELENG_5 or RELENG_5_3 or is CURRENT required? Do you have this in some public depository already? Pete > David Xu > > Petri Helenius wrote: > >> >> Hi, >> >> I have some low-contention mutexes which I'm trying to make perform >> better and I'm wondering if the current threading library does have >> some primitives I could use or if I'm better off using >> atomic_cmpset_* and pthread_yield() if the thread hit's contention >> (which should be about 1:10000 of the lock/unlock operation). >> >> Any scheduling caveats from above, except obviously it would spin >> while waiting for the lock. Most systems I plan on running this on >> have dual-hypethreading CPU's. >> >> I remember there were some discussion about dropping i386 compatible >> support for mutexes and using atomic operations instead. Is there >> code/compile time options for this on a branch I could check out and >> give it a spin? >> >> 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 Thu Jan 6 09:22:45 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 7E98A16A4CE for ; Thu, 6 Jan 2005 09:22:45 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AECD43D3F; Thu, 6 Jan 2005 09:22:45 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j069MfvA004667; Thu, 6 Jan 2005 09:22:43 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41DD04FE.7070409@freebsd.org> Date: Thu, 06 Jan 2005 17:29:34 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Helenius References: <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org> <41DD01CE.70004@he.iki.fi> In-Reply-To: <41DD01CE.70004@he.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: higher speed mutexes 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, 06 Jan 2005 09:22:45 -0000 Petri Helenius wrote: > David Xu wrote: > >> I will have low overhead pthread library available soon, for >> simple mutex, it is only an atomic_cmpset_long() plus a function >> call (pthread_mutex_lock) overhead. >> > Sounds great. Will this change the performance of rwlocks or is simple > mutex preferred for performance sensitive applications? because we use simple mutex to protect rwlock, if simple mutex is improved, rwlock should be improved by this side effect. > Is this something that I could drop on top of RELENG_5 or RELENG_5_3 or > is CURRENT required? > Do you have this in some public depository already? > you can browse my perforce repository, it requires -CURRENT and when I put it to public, it will need newest -CURRENT kernel. ;-) http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/davidxu%5fthread/src/lib/libthread/thread > Pete > David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Jan 6 16:35:40 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 361B616A4CE; Thu, 6 Jan 2005 16:35:40 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1CCB43D54; Thu, 6 Jan 2005 16:35:38 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j06GZbc4073673; Thu, 6 Jan 2005 18:35:37 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <41DD68DB.6040405@he.iki.fi> Date: Thu, 06 Jan 2005 18:35:39 +0200 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org> <41DD01CE.70004@he.iki.fi> <41DD04FE.7070409@freebsd.org> In-Reply-To: <41DD04FE.7070409@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: higher speed mutexes 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, 06 Jan 2005 16:35:40 -0000 David Xu wrote: > > > because we use simple mutex to protect rwlock, if simple mutex is > improved, rwlock should be improved by this side effect. > But rwlock will be significantly more expensive than a simple mutex when uncontested, right? > you can browse my perforce repository, it requires -CURRENT and when > I put it to public, it will need newest -CURRENT kernel. ;-) Is this on the "merge path" to 5.4 or only 6.0? Pete From owner-freebsd-threads@FreeBSD.ORG Thu Jan 6 20:13:20 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 5BF4E16A4CE for ; Thu, 6 Jan 2005 20:13:20 +0000 (GMT) Received: from web51609.mail.yahoo.com (web51609.mail.yahoo.com [206.190.38.214]) by mx1.FreeBSD.org (Postfix) with SMTP id D0C2A43D49 for ; Thu, 6 Jan 2005 20:13:19 +0000 (GMT) (envelope-from giffunip@yahoo.com) Received: (qmail 57435 invoked by uid 60001); 6 Jan 2005 20:13:19 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=p4bXfk/LO46u8G6gIQKdhew0892CAGC7mKYYLuwPe46mUxpp7JHUBFh8nVVfy4PhdiVDKN9RXCLiNbVfYAzRCWBEy2qfKnL/MgGJUB6y4+B4a+iEAqx6/3hB+l6HU/wzukZHs/bbKBDL+9fVAV7kY9OaTYo7NphFxF+mPLqMbK4= ; Message-ID: <20050106201319.57433.qmail@web51609.mail.yahoo.com> Received: from [200.119.73.60] by web51609.mail.yahoo.com via HTTP; Thu, 06 Jan 2005 12:13:18 PST Date: Thu, 6 Jan 2005 12:13:18 -0800 (PST) From: "Pedro F. Giffuni" To: freebsd-threads@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Cthreads for FreeBSD 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, 06 Jan 2005 20:13:20 -0000 Hi again; With some spare time on my hands, I wanted to follow up on an idea I had some time ago about porting Mach's Cthreads to use KSE: this would probably make it easier for us to port Darwin stuff, and provide a different threaded library option. I found this link that seems very near to what would be needed: http://www.cc.gatech.edu/systems/projects/Cthreads/ Unfortunately either the download link is broken or they restrict access to ppp links :(. I asked the maintainer for an updated version (and a link). Anyways... if anyone that knows about threads would like to provide indications on how it should be done (or "simply" do it :-P), it would be great! Pedro. __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From owner-freebsd-threads@FreeBSD.ORG Fri Jan 7 18:46:39 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 296B516A4CE for ; Fri, 7 Jan 2005 18:46:39 +0000 (GMT) Received: from bute.st-andrews.ac.uk (bute.st-and.ac.uk [138.251.12.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DB1F43D39 for ; Fri, 7 Jan 2005 18:46:38 +0000 (GMT) (envelope-from s_sourceforge@nedprod.com) Received: from kate (res04-ned6.res.st-and.ac.uk [138.251.234.67]) by bute.st-andrews.ac.uk (8.9.1a/8.9.1) with SMTP id SAA15653 for ; Fri, 7 Jan 2005 18:44:08 GMT From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Fri, 07 Jan 2005 18:46:05 -0000 MIME-Version: 1.0 Message-ID: <41DED8ED.32740.96446B0@localhost> Priority: normal In-reply-to: <41DD68DB.6040405@he.iki.fi> References: <41DD04FE.7070409@freebsd.org> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Subject: Re: higher speed mutexes 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, 07 Jan 2005 18:46:39 -0000 On 6 Jan 2005 at 18:35, Petri Helenius wrote: > > because we use simple mutex to protect rwlock, if simple mutex is > > improved, rwlock should be improved by this side effect. > > > But rwlock will be significantly more expensive than a simple mutex > when uncontested, right? I have a highly optimised rwlock mutex implementation at http://svn.berlios.de/viewcvs/tnfox/trunk/src/FXThread.cxx?rev=52&view =markup. If uncontested, it requires no more than a variable increment and a TLS variable increment (with corresponding complexity for unlocking) for read locking and four variable increments, three variable stores, one TLS variable read for write locking. It's also fully recursive. Cheers, Niall From owner-freebsd-threads@FreeBSD.ORG Sat Jan 8 14:26:39 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 D4A7016A4CF for ; Sat, 8 Jan 2005 14:26:39 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE3FD43D49; Sat, 8 Jan 2005 14:26:39 +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 j08EQZjA059440; Sat, 8 Jan 2005 14:26:38 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41DFED9A.8070202@freebsd.org> Date: Sat, 08 Jan 2005 22:26:34 +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: Petri Helenius References: <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org> <41DD01CE.70004@he.iki.fi> In-Reply-To: <41DD01CE.70004@he.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: higher speed mutexes 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, 08 Jan 2005 14:26:39 -0000 Petri Helenius wrote: > David Xu wrote: > >> I will have low overhead pthread library available soon, for >> simple mutex, it is only an atomic_cmpset_long() plus a function >> call (pthread_mutex_lock) overhead. >> > Sounds great. Will this change the performance of rwlocks or is simple > mutex preferred for performance sensitive applications? > Is this something that I could drop on top of RELENG_5 or RELENG_5_3 > or is CURRENT required? > Do you have this in some public depository already? > I have put it there: http://people.freebsd.org/~davidxu/libthread.tgz It can only run on newest -CURRENT kernel. It is a simplified version of libpthread plus some ideas from libthr. It is different with libpthread, it uses thr + umtx interfaces and does not have signal wrapper, it is in very simple shape. I have rewritten simple mutex code to use umtx cmpset atomic instruction. Condition variable code is also rewritten, now simple mutex and condition variable both can be shared between processes once pthread.h is changed to define mutex and other synchronization objects in C structure style (current it was typedefed as a structure pointer, which prevents them from being shared between processes via mmap() ), also I believe semaphore and rwlock can also be shared between processes once pthread.h is updated. In detail, I don't use thr_suspend and thr_wakeup, I use more reliable way: umtx_wait + umtx_wake, I have added them into kernel sometimes ago. So I would like to see this library in tree, and let me start to work on process sharable synchronization objects in near future. David Xu From owner-freebsd-threads@FreeBSD.ORG Sat Jan 8 18:24:43 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 D14D616A4CF; Sat, 8 Jan 2005 18:24:43 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56E2D43D49; Sat, 8 Jan 2005 18:24:42 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j08IOd4v002596; Sat, 8 Jan 2005 20:24:40 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <41E0256A.1000801@he.iki.fi> Date: Sat, 08 Jan 2005 20:24:42 +0200 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org> <41DD01CE.70004@he.iki.fi> <41DFED9A.8070202@freebsd.org> In-Reply-To: <41DFED9A.8070202@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: higher speed mutexes 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, 08 Jan 2005 18:24:43 -0000 David Xu wrote: > Petri Helenius wrote: > >> David Xu wrote: >> >>> I will have low overhead pthread library available soon, for >>> simple mutex, it is only an atomic_cmpset_long() plus a function >>> call (pthread_mutex_lock) overhead. >>> >> Sounds great. Will this change the performance of rwlocks or is >> simple mutex preferred for performance sensitive applications? >> Is this something that I could drop on top of RELENG_5 or RELENG_5_3 >> or is CURRENT required? >> Do you have this in some public depository already? >> > I have put it there: > http://people.freebsd.org/~davidxu/libthread.tgz > It can only run on newest -CURRENT kernel. Is this something that is going to appear on 5.x eventually or only 6.0 ? > > It is a simplified version of libpthread plus some ideas from libthr. > It is different with libpthread, it uses thr + umtx interfaces and does > not have signal wrapper, it is in very simple shape. Does this say that signal handling is broken/non-functional with this library or that it does not need it to work properly? > I have rewritten simple mutex code to use umtx cmpset atomic instruction. > Condition variable code is also rewritten, now simple mutex and condition > variable both can be shared between processes once pthread.h is changed > to define mutex and other synchronization objects in C structure style > (current it was typedefed as a structure pointer, which prevents them > from > being shared between processes via mmap() ), also I believe semaphore > and rwlock can also be shared between processes once pthread.h is > updated. What happens if the process holding the lock dies? > In detail, I don't use thr_suspend and thr_wakeup, I use more reliable > way: > umtx_wait + umtx_wake, I have added them into kernel sometimes ago. > I was looking at the umtx routines and wondering if I could use them instead of pthread API. > So I would like to see this library in tree, and let me start to work on > process sharable synchronization objects in near future. I assume the code using these libraries need also to be recompiled from 5.3 ? Pete