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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christopher Friesen wrote:
Howard Chu wrote:

Robert Hancock wrote:

> This says nothing about requiring a reschedule. The "scheduling policy"
 > can well decide that the thread which just released the mutex can
 > re-acquire it.

No, because the thread that just released the mutex is obviously not one of the threads blocked on the mutex. When a mutex is unlocked, one of the *waiting* threads at the time of the unlock must acquire it, and the scheduling policy can determine that. But the thread the released the mutex is not one of the waiting threads, and is not eligible for consideration.

Is it *required* that the new owner of the mutex is determined at the time of mutex release?

If the kernel doesn't actually determine the new owner of the mutex until the currently running thread swaps out, it would be possible for the currently running thread to re-aquire the mutex.

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.

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.)

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/

-
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]
  Powered by Linux