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.
As I said in previous email, I would rather see our default
mutex implementations improved instead of adding new interfaces.
If it's really necessary in the short term, perhaps an
environment variable that can be set to force all mutexes
to be adaptive (and when kern.smp.cpus > 1 perhaps?).
Yes, an environment variable is good idea.
Regards,
David Xu
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
