Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)

From: Robert Hancock
Date: Wed Jan 25 2006 - 19:09:58 EST


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 hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/