lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
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@nospamshaw.ca
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-26 01:14    [W:1.521 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site