Messages in this thread | | | Date | Thu, 26 Jan 2006 15:14:46 +0900 | From | Samuel Masham <> | Subject | Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) |
| |
On 26/01/06, Lee Revell <rlrevell@joe-job.com> wrote: > On Thu, 2006-01-26 at 13:02 +0900, Samuel Masham wrote: > > On 26/01/06, Samuel Masham <samuel.masham@gmail.com> wrote: > > > comment: > > > As a rt person I don't like the idea of scheduler bounce so the way > > > round seems to be have the mutex lock acquiring work on a FIFO like > > > basis. > > > > which is obviously wrong... > > > > Howeve my basic point stands but needs to be clarified a bit: > > > > I think I can print non-compliant if the mutex acquisition doesn't > > respect the higher priority of the waiter over the current process > > even if the mutex is "available". > > > > OK? > > I don't think using an optional feature (PI) counts... > > Lee
So when acquiring a mutex with pi enabled must involve scheduler...
... and you can skip that bit with it disabled as one can argue that the user can't tell if the time slice hit between the call to acquire the mutex and the actual mutex wait itself?
sounds a bit of a fudge to me....
I assume that mutexes will must never support a the wchan (proc) interface or the like?
On the other hand the basic point about high contention around mutexes and relying on this being a bad idea is fine by me.
Samuel - 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/
| |