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