Date: Fri, 25 Mar 2005 07:19:07 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
Message-ID: <20050325061907.GA20242@elte.hu>
References: <20050324113912.GA20911@elte.hu> <Pine.OSF.4.05.10503242307330.25274-100000@da410.phys.au.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.OSF.4.05.10503242307330.25274-100000@da410.phys.au.dk>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 941
Lines: 21


* Esben Nielsen <simlo@phys.au.dk> wrote:

> I like the idea of having the scheduler take care of it - it is a very 
> optimal coded queue-system after all. That will work on UP but not on 
> SMP. Having the unlock operation to set the mutex in a "partially 
> owned" state will work better. The only problem I see, relative to 
> Ingo's implementation, is that then the awoken task have to go in and 
> change the state of the mutex, i.e. it has to lock the wait_lock 
> again. Will the extra schedulings being the problem happen offen 
> enough in practise to have the extra overhead?

i think this should be covered by the 'unschedule/unwakeup' feature, 
mentioned in the latest mails.

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