cvs commit: src/lib/libthr/thread thr_mutex.c
src/lib/libkse/thread thr_mutex.c src/include pthread.h
davidxu at FreeBSD.org
Tue Oct 30 02:04:20 PDT 2007
Kris Kennaway wrote:
> David Xu 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 ;-)
>> Isn't this commit an incident too ? :-) if it is not, then
>> we should retire from FreeBSD now, as two thread library
>> maintainers were bypassed.
> Hi David,
> I'm honestly a bit surprised to hear that you consider yourself to be
> the maintainer of this code, because while you have certainly worked
> heavily on it in the past, I have sent several mails to you over the
> past year or so raising various problems and ideas I have encountered in
> the libthr and related code while working on performance tuning, and you
> have declined to reply to many of them, or to participate in the ongoing
> optimization work.
At least I am maintainer of libthr today unless I am replaced
tommorrow. In fact, I am surpised to that this mutex type was added
without public discussion, or even discussed with Dan.
I did post a patch that said I was implementing spin mutex, as you can
see, my last commit also has _sched_yield() loop, which may further
helps performance. I did lots of work to improve mutex performance,
for example I had code spinning in kernel for umtx but backed it out
since I thought it is not mature. another is shared page idea, julian
just said, in fact it is an old discussion with julian and jhb, you
just don't know it.
> That being said, it's only an "incident" if you choose to be offended by
> the commit.
> I'd recommend instead focusing on the technical issues, specifically the
> fact that there does not exist a better alternative way to do this at
> the present date. I have discussed the reasons why in my previous
> emails (in particular, an env variable is inappropriate), so please
> refer to those specifc points in formulating any further reply.
> Jeff, Attilio and I have ideas about how we might be able to improve the
> libthr and umtx code going forward, so we'd be delighted to have your
> help in working on them.
My last commit improves mysql select-smack benchmark on 4-core xeon from
48000 queries/s to 70000 queries/s, so my work is alternative way, I
think adding new mutex type should be publically discussed rather
than rushing into the source tree, since it adding new interfaces which
have to be supported in future.
More information about the cvs-all