Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

[Bill Huey (hui) <billh@gnuppy.monkey.org>]

On Fri, Dec 16, 2005 at 11:34:03PM -0800, Linus Torvalds wrote:
> For example, to make things really concrete, please just name a semaphore 
> that is relevant to a real-time task and that isn't fine enough grain that 
> a careful and controlled environment can't avoid it being a bottle-neck 
> for a real-time task.

Problem here is ownership tracking with a semaphore is an extremely difficult
problem to solve without serializing the entire thing with a single spinlock.
You lose parallelism here and possible create other problems since the
contention window is larger surround critical sections using it.

> The real problems often end up happening in things like memory management, 
> and waiting for IO, where it's not about the locking at all, it's about 
> event scheduling. And you just have to avoid those (through pre-allocation 
> and buffering) in those kinds of real-time situations.
> 
> I really can't think of any blocking kernel lock where priority 
> inheritance would make _any_ sense at all. Please give me an example. 

The current kernel mostly using traditional spinlocks doesn't have locking
complicated enough to warrant it. However, the -rt patch does create a
circumstance where a fully preemptible may sleep task with mutexes held create
and needs resolve priority inversions that results from it. That's of
course assuming that priority is something that needs to be strictly
obeyed in this variant of the kernel with consideration to priority
inheritance.

bill

-
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/