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

Nick Piggin wrote: 
OK, you believe that the mutex *must* be granted to a blocking thread
at the time of the unlock. I don't think this is unreasonable from the
wording (because it does not seem to be completely unambiguous english),
however think about this -

A realtime system with tasks A and B, A has an RT scheduling priority of
1, and B is 2. A and B are both runnable, so A is running. A takes a mutex
then sleeps, B runs and ends up blocked on the mutex. A wakes up and at
some point it drops the mutex and then tries to take it again.

What happens?

I haven't programmed realtime systems of any complexity, but I'd think it
would be undesirable if A were to block and allow B to run at this point.

But why does A take the mutex in the first place? Presumably because it is about to execute a critical section. And also presumably, A will not release the mutex until it no longer has anything critical to do; certainly it could hold it longer if it needed to.

If A still needed the mutex, why release it and reacquire it, why not just hold onto it? The fact that it is being released is significant.

Now this has nothing to do with PI or SCHED_OTHER, so behaviour is exactly
determined by our respective interpretations of what it means for "the
scheduling policy to decide which task gets the mutex".

What have I proven? Nothing ;) but perhaps my question could be answered
by someone who knows a lot more about RT systems than I.

In the last RT work I did 12-13 years ago, there was only one high priority producer task and it was never allowed to block. The consumers just kept up as best they could (multi-proc machine of course). I've seldom seen a need for many priority levels. Probably not much you can generalzie from this though.

--
 -- 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Relevant Pages

  • Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
    ... > Mutexes layered on existing semaphores seems convenient ... I.e. the task with the highest priority get ... Then on top of that you build your mutex. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: FUSYN and RT
    ... task_struct to retain the old priority. ... The RT mutex can safely save the owner ... priority with out a Fusyn jumping in and changing it and the other way ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... A realtime system with tasks A and B, A has an RT scheduling priority of ... B runs and ends up blocked on the mutex. ... to take a lock that is incompatible with the lock already being held, ... we expect a higher priority process to take it. ...
    (Linux-Kernel)
  • Re: Xterm Hangs - Possible scheduler defect?
    ... > Ingo Oeser wrote: ... >> his and all the waiters on it, until it releases his mutex, where he regains ... >> its old priority after release of mutex. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Xterm Hangs - Possible scheduler defect?
    ... Ingo Oeser wrote: ... > You would need to change the priority of task 1 until it releases the ... > his and all the waiters on it, until it releases his mutex, where he regains ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)