Re: FUSYN and RT
From: Daniel Walker (dwalker_at_mvista.com)
Date: 04/13/05
- Previous message: George Anzinger: "Re: [PATCH] Maintainers list update: linux-net -> netdev"
- Maybe in reply to: Daniel Walker: "FUSYN and RT"
- Next in thread: Perez-Gonzalez, Inaky: "RE: FUSYN and RT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Esben Nielsen <simlo@phys.au.dk> Date: 12 Apr 2005 15:15:59 -0700
On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
> You basicly need 3 priorities:
> 1) Actual: task->prio
> 2) Base prio with no RT locks taken: task->static_prio
> 3) Base prio with no Fusyn locks taken: task->??
>
> So no, you will not need the same API, at all :-) Fusyn manipulates
> task->static_prio and only task->prio when no RT lock is taken. When the
> first RT-lock is taken/released it manipulates task->prio only. A release
> of a Fusyn will manipulate task->static_prio as well as task->prio.
mutex_setprio() , I don't know if you could call that an API but that's
what I was talking about.. They should both use that. I think it would
be better if the RT mutex (and fusyn) didn't depend on a field in the
task_struct to retain the old priority. That would make it easier ..
This goes back to the assumption that the locking isn't intermingled
once you get into the kernel . The RT mutex can safely save the owner
priority with out a Fusyn jumping in and changing it and the other way
around..
Daniel
-
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/
- Previous message: George Anzinger: "Re: [PATCH] Maintainers list update: linux-net -> netdev"
- Maybe in reply to: Daniel Walker: "FUSYN and RT"
- Next in thread: Perez-Gonzalez, Inaky: "RE: FUSYN and RT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
