Howard Chu wrote:
The SUSv3 text seems pretty clear. It says "WHEN pthread_mutex_unlock()
is called, ... the scheduling policy SHALL decide ..." It doesn't say
MAY, and it doesn't say "some undefined time after the call." There is
nothing optional or implementation-defined here. The only thing that is
not explicitly stated is what happens when there are no waiting threads;
in that case obviously the running thread can continue running.
It says the scheduling policy will decide who gets the mutex. It does
not say that such a decision must be made immediately. That seems rather
implementation defined to me.
re: forcing the mutex to ping-pong between different threads - if that
is inefficient, then the thread scheduler needs to be tuned differently.
Threads and thread context switches are supposed to be cheap, otherwise
you might as well just program with fork() instead. (And of course, back
when Unix was first developed, *processes* were lightweight, compared to
other extant OSs.)
This is nothing to do with the thread scheduler being inefficient. It is
inherently inefficient to context-switch repeatedly no matter how good
the kernel is. It trashes the CPU pipeline, at the very least, can cause
thrashing of the CPU caches, and can cause cache lines to be pushed back
and forth across the bus on SMP machines which really kills performance.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
