From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4D9230C5.7050007@domain.hid> Date: Tue, 29 Mar 2011 21:19:33 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <1301412534.2109.24.camel@domain.hid> <4D922EF5.8020808@domain.hid> <1301426227.2109.35.camel@domain.hid> In-Reply-To: <1301426227.2109.35.camel@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Priority coupling broken? List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org Philippe Gerum wrote: > On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote: >> Philippe Gerum wrote: >>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote: >>>> Hi, >>>> >>>> I have several Xenomai RT threads (prio > 0) that get ready to run all >>>> at the same time. Priority coupling is enabled in the kernel. >>>> >>>> If one of them (unfortunately) makes a Linux system call, I see that >>>> first other lower and same priority Xenomai tasks are scheduled before >>>> the switched task is run in the Linux domain. As I understand, >>>> priority coupling should prevent this. >>>> >>>> To rule out a problem in the application, this is also tested with a >>>> simple application based on the rt_print example. In my opinion, with >>>> priority coupling enabled this should print: >>>> Wakeup! - I am - awake! - Me too! >>>> But I get: >>>> Wakeup! - I am - Me too! - awake! >>>> So task 2 gets run before task 3 completes in the Linux domain. >>>> >>>> Please find attached the test application and the .config file. >>> The fine print with priority coupling is that it stops immediately >>> whenever the thread blocks linux-wise; this is actually why, after all >>> this time debugging it, I'm pondering now whether I should keep this >>> behavior/feature in 3.x. >>> >>> Initially, this was aimed at enforcing the right scheduling sequence >>> with traditional RTOS APIs, specifically when it comes to create >>> threads, so that high priority children do run prior to low priority >>> parents (some legacy apps may expect this). But the fact is that this >>> behavior also carries a number of uncertainties, and having the thread >>> de-boosted when blocked by Linux is a serious one. >> Maybe each thread could have a bit telling whether or not it should run >> under priority coupling, this bit would be disabled at all times, except >> during the thread creation routines, and at other times if the user >> called xnpod_set_mode to enable it if he wants? >> > > This bit exists, it is XNRPIOFF. What I'm pondering is whether this all > makes sense to provide priority coupling without any mean to actually > control the impact the regular kernel may have on it. > without the irq shield you mean :-) -- Gilles.