Date: Thu, 06 Jan 2005 11:15:58 +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: <41DD01CE.70004@he.iki.fi> In-Reply-To: <41DCFD2F.2040207@freebsd.org> References: <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41DD01CE.70004>