cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h

[David Xu]

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.
> 
> Kris
> 

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.