Date: Mon, 29 Oct 2007 22:52:15 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Daniel Eischen <deischen@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h Message-ID: <4726560F.5050804@FreeBSD.org> In-Reply-To: <Pine.GSO.4.64.0710291732090.19572@sea.ntplx.net> References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <Pine.GSO.4.64.0710291712100.19572@sea.ntplx.net> <472650BF.5060706@FreeBSD.org> <Pine.GSO.4.64.0710291732090.19572@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Mon, 29 Oct 2007, Kris Kennaway wrote: > >> Daniel Eischen wrote: >>> >>> The libkse implementation already spins for a bit. The default >>> number of spins is 500. >> >> OK, cool. >> >>> I'm not sure that another mutex type is warranted, the default >>> mutex implementation should be adaptive I think. >> >> The point being that certain existing applications already know about >> this mutex name and will use it automatically when it exists. >> >> I am a bit wary of making this the default type though. The algorithm >> is a pessimization when the conditions described above are not true. > > I agree, and it applies a little to the KSE approach also. > Spinning is mostly a hack for not being able to tell in > userland if a thread is swapped in/out or is on another > CPU. If you solve that problem, then you can make the > default mutex adaptive. Yeah. It looks like Solaris does this. In principle you could do it cheaply with a shared page, I'm not sure what Solaris does. One further optimization that can be done is for umtx to also spin when the mutex holder is running instead of sleeping immediately. Jeff and I hope to look at this. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4726560F.5050804>