Date: Mon, 29 Oct 2007 21:00:42 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "David Xu" <davidxu@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, cvs-src@freebsd.org, Kris Kennaway <kris@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: <b1fa29170710292100v56ad4d83v37836cfb41e856d4@mail.gmail.com> In-Reply-To: <47269AD0.3080906@freebsd.org> References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <47268F17.1000106@freebsd.org> <Pine.GSO.4.64.0710292207140.19572@sea.ntplx.net> <47269AD0.3080906@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/29/07, David Xu <davidxu@freebsd.org> wrote: > Daniel Eischen wrote: > > On Tue, 30 Oct 2007, David Xu wrote: > > > >> I am not sure PTHREAD_MUTEX_ADAPTIVE_NP is a correct solution, in fact > >> I think this is Linux crap, shouldn't PTHREAD_PRIO_PROTECT and > >> PTHREAD_PRIO_INHERIT mutex be adaptivly spinned ? > >> also this commit does not change mutex_self_lock() to handle the > >> PTHREAD_MUTEX_ADAPTIVE_NP, what is the PTHREAD_MUTEX_ADAPTIVE_NP > >> definition when the mutex is already locked by the currect thread ? > >> deadlock or return error code ? > > > > > > I tend to agree with the "Linux crap" comment, but I hesitate > > to use those words considering the recent sensor framework > > incident ;-) > > Perhaps. I'm sure Kris would welcome you working more closely with him in his tuning efforts. We should all be thankful both that you're working on libthr and that Kris has put so much time into making FreeBSD a better performing platform. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170710292100v56ad4d83v37836cfb41e856d4>