Daniel Eischen wrote:
When I removed this hack (i.e. revert to pthread_yield()) I got an
immediate 7-fold performance increase, which brings FreeBSD
performance on par with Solaris.
What is the reason why this code is necessary? Does FreeBSD's
sched_yield() really have different semantics to the other operating
systems, or was this a libkse bug that was being worked around?
It's certainly not a libkse bug, at least with scope process threads
libkse does the right thinng. For scope system threads and all libthr
threads, it probably depends on what scheduler you are using since
it's essentially a __sys_sched_yield().
On a side note, I think pthread_yield() is deprecated and not in the
latest POSIX spec. sched_yield() is in the spec and is specified
to account for behavior in a threaded environment.
Yeah, libthr's pthread_yield just calls sched_yield. Anyway, it seems
to me that the decision of what thread to run next is a scheduler
decision, and if it is inappropriate for some reason for a scheduler to
possibly choose to reschedule the same thread that just yielded, this is
something that should be addressed in the scheduler rather than by
adding hacks to the application.
Kris
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
