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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
