Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262975AbVDLXRk (ORCPT ); Tue, 12 Apr 2005 19:17:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263054AbVDLXPC (ORCPT ); Tue, 12 Apr 2005 19:15:02 -0400 Received: from lirs02.phys.au.dk ([130.225.28.43]:12214 "EHLO lirs02.phys.au.dk") by vger.kernel.org with ESMTP id S262975AbVDLXLb (ORCPT ); Tue, 12 Apr 2005 19:11:31 -0400 Date: Wed, 13 Apr 2005 01:11:01 +0200 (METDST) From: Esben Nielsen To: "Perez-Gonzalez, Inaky" Cc: Daniel Walker , linux-kernel@vger.kernel.org, mingo@elte.hu Subject: RE: FUSYN and RT In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DAIMI-Spam-Score: 0 () Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3659 Lines: 92 I think we (at least) got a bit confused here. What (I think) the thread started out with was a clear layering of the mutexes. I.e. the code obeys the grammar VALID_LOCK_CODE = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN | VALID_LOCK_CODE VALID_LOCK_CODE | VALID_RTLOCK_CODE VALID_RTLOCK = LOCK_RTLOCK VALID_RTLOCK_CODE UNLOCK_RTLOCK | VALID_RTLOCK_CODE VALID_RTLOCK_CODE | VALID_SPINLOCK_CODE | (code with no locks at all) VALID_SPINLOCK_CODE = ... :-) In that context the case is simple: Fusyn's and RT-locks can easily co-exist. One only need an extra level akin to static_prio to fall back to when the last fusyn is unlocked. The API's should be _different_, but fusyn_setprio() should both update static_prio and call mutex_setprio(). There will never be deadlocks involving both types of locks, as Daniel said because the lock nesting is sorted out. Furtheremore, unbalanced (incorrect) code like LOCK_FUSYN VALID_RTLOCK_CODE (no unlock) will never hit the RT-level. So assuming the RT-lock based code is debugged the error must be in Fusyn based code. Esben On Tue, 12 Apr 2005, Perez-Gonzalez, Inaky wrote: > >From: Esben Nielsen [mailto:simlo@phys.au.dk] > >On 12 Apr 2005, Daniel Walker wrote: > > > >> > >> > >> At least, both mutexes will need to use the same API to raise and > lower > >> priorities. > > > >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. > > Yes you do. You took care of the simple case. Things get funnier > when you own more than one PI lock, or you need to promote a > task that is blocked on other PI locks whose owners are blocked > on PI locks (transitivity), or when you mix PI and PP (priority > protection/ priority ceiling). > > In that case not having a sim{pl,g}e API for doing it is nuts. > > >> The next question is deadlocks. Because one mutex is only in the > kernel, > >> and the other is only in user space, it seems that deadlocks will > only > >> occur when a process holds locks that are all the same type. > > > >Yes. > >All these things assumes a clear lock nesting: Fusyns are on the outer > >level, RT locks on the inner level. What happens if there is a bug in > RT > >locking code will be unclear. On the other hand errors in Fusyn locking > >(user space) should not give problems in the kernel. > > Wrong. Fusyns are kernel locks that are exposed to user space (much as > a file descriptor is a kernel object exposed to user space through > a system call). Of course if the user does something mean with them > they will cause an error, but should not have undesired consequences > in the kernel. But BUGS in the code will be as unclear as in RT mutexes. > > >it is is bad maintainance to have to maintain two seperate systems. The > >best way ought to be to try to only have one PI system. The kernel is > big > >and confusing enough as it is! > > Ayeh for the big...it is not that confusing :) > > -- Inaky > - 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/