From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
Date: Fri, 16 Dec 2005 22:42:30 UTC
Message-ID: <fa.g09t5bi.h0g5qg@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0512161439330.3698@g5.osdl.org>

On Fri, 16 Dec 2005, Thomas Gleixner wrote:
>
> Therefor, if you want to handle that "init protection" scenario, do not
> use a mutex, because the owner can not be defined at compile -
> allocation time.

Sure it could. We certainly have "init_task", for example. It may or may
not be the right thing to use, of course. Depends on what the situation
is.

> You can still implement (chose a mechanism) a mutex on top - or in case
> of lack of priority inheritance or debugging with exactly the same -
> mechanism as a semaphore, but this does not change the semantical
> difference at all.

"Friends don't let friends use priority inheritance".

Just don't do it. If you really need it, your system is broken anyway.

		Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
Date: Sat, 17 Dec 2005 01:01:25 UTC
Message-ID: <fa.g1a95jg.i0s42u@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0512161647570.3698@g5.osdl.org>

On Fri, 16 Dec 2005, Joe Korty wrote:
>
> The Mars Pathfinder incident is sufficient proof that some solution to
> the priority inversion problem is required in real systems.

Ehh.

The Mars Pathfinder is just about the worst case "real system", and if I
recall correctly, the reason it was able to continue was _not_ because it
handled priority inversion, but because it reset itself every 24 hours or
something like that, and had debugging facilities..

The _real_ lesson you should take away from it is not that priority
inheritance is a good solution to priority inversion, but that having a
failsafe switch when everthing goes wrong is critical. You don't know
_what_ bug you'll encounter.

The bug itself could have been solved without priority inheritance,
although I think in this case enabling that in VxWorks was the particular
solution to the problem as being the least invasive.

Personally, I don't care what user space does. If some app wants to use
priority inheritance to solve its bugs, that's fine. But it's like
recursive locks: it's generally a _bandaid_ for bad locking. I definitely
don't want the kernel depending on either.

So put a watchdog on your critical systems, and make sure you can debug
them. Especially if they're on Mars.

			Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
Date: Sat, 17 Dec 2005 07:35:20 UTC
Message-ID: <fa.fvpt53c.hgg5iq@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0512162323140.3698@g5.osdl.org>

On Fri, 16 Dec 2005, Steven Rostedt wrote:
>
> So how does one handle real-time tasks that must contend with locks within
> the kernel that is shared with low priority tasks?  Do you prefer the RTAI
> approach?

If you want hard real-time, either that, or just make sure you don't get
locks that might be slow (for one reason or another). Finer granularities
help there.

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.

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.

			Linus