Date: Sat, 08 Jan 2005 20:24:42 +0200 From: Petri Helenius <pete@he.iki.fi> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: higher speed mutexes Message-ID: <41E0256A.1000801@he.iki.fi> In-Reply-To: <41DFED9A.8070202@freebsd.org> References: <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org> <41DD01CE.70004@he.iki.fi> <41DFED9A.8070202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41E0256A.1000801>