Date: Thu, 24 Mar 2005 19:17:52 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Esben Nielsen <simlo@phys.au.dk>
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
Message-ID: <20050324181752.GA25412@elte.hu>
References: <20050322100153.GA23143@elte.hu> <20050322112856.GA25129@elte.hu> <20050323061601.GE1294@us.ibm.com> <20050323063317.GB31626@elte.hu> <20050324052854.GA1298@us.ibm.com> <20050324053456.GA14494@elte.hu> <Pine.LNX.4.58.0503240310490.18714@localhost.localdomain> <Pine.LNX.4.58.0503240341280.18714@localhost.localdomain> <20050324113912.GA20911@elte.hu> <Pine.LNX.4.58.0503240916210.18714@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0503240916210.18714@localhost.localdomain>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 945
Lines: 22


* Steven Rostedt <rostedt@goodmis.org> wrote:

> On an SMP machine, there may even be a chance of a lower priority 
> process that gets it. That would be possible if the low priority 
> process on the other CPU tries to grab the lock just after it was 
> released but before the just woken up high priorty processes get 
> scheduled. So there's a window where the lock is open, and the lower 
> priority process snagged it just before the others got in.

that's always a possibility, on UP too: if a lower priority task manages 
to acquire a lock 'just before' a highprio thread got interested in it 
there's no way to undo that.

but for the other reasons the explicit approach looks better.

	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/