Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Thomas Necker]

Hi Philippe

> > non-preemptive mode.
> > With original pSOS this was allowed and "non-preemptive" meant that a
> > runnable task cannot be preempted by other tasks but can block itself.
> > Why is this different in Xenomai and is it possible to implement the 
same
> > behaviour in Xenomai core?
> > 
> 
> Xenomai implements the non-preemptible mode as most RTOSes implement
> scheduling locks. From this POV, allowing a non-preemptible task to
> block makes no sense, and doing so usually either locks up the board, or
> causes an API error.
> 
> It could be possible to switch the preemption bit on before entering a
> blocking state only for pSOS tasks, then reinstate it when the task
> wakes up, though. However, before going down that path, is there any
> pSOS documentation that clearly states that such behaviour is to be
> expected (i.e. that blocking calls _may_ be called in non-preemptible
> mode)?
> 
> Or did you benefit from an undocumented and fortunate side-effect of the
> pSOS implementation when relying on such behaviour?

Since Markus has already left, I had a quick look in the pSOS System 
Concepts Manual:

    Each task has a mode word, with two settable bits that can affect 
scheduling.
    One bit controls the task's preemptibility. If disabled, then once the 
task
    enters the running state, it will stay running even if other tasks
    of higher priority enter the ready state. A task switch will occur 
only if
    the running task blocks, or if it re-enables preemption.

So it clearly states that a non-preemtible task may block (and 
rescheduling occurs in
this case).

Regards,
Thomas

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Philippe Gerum]

On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> Hi Philippe
> 
> > > non-preemptive mode.
> > > With original pSOS this was allowed and "non-preemptive" meant that a
> > > runnable task cannot be preempted by other tasks but can block itself.
> > > Why is this different in Xenomai and is it possible to implement the 
> same
> > > behaviour in Xenomai core?
> > > 
> > 
> > Xenomai implements the non-preemptible mode as most RTOSes implement
> > scheduling locks. From this POV, allowing a non-preemptible task to
> > block makes no sense, and doing so usually either locks up the board, or
> > causes an API error.
> > 
> > It could be possible to switch the preemption bit on before entering a
> > blocking state only for pSOS tasks, then reinstate it when the task
> > wakes up, though. However, before going down that path, is there any
> > pSOS documentation that clearly states that such behaviour is to be
> > expected (i.e. that blocking calls _may_ be called in non-preemptible
> > mode)?
> > 
> > Or did you benefit from an undocumented and fortunate side-effect of the
> > pSOS implementation when relying on such behaviour?
> 
> Since Markus has already left, I had a quick look in the pSOS System 
> Concepts Manual:
> 
>     Each task has a mode word, with two settable bits that can affect 
> scheduling.
>     One bit controls the task's preemptibility. If disabled, then once the 
> task
>     enters the running state, it will stay running even if other tasks
>     of higher priority enter the ready state. A task switch will occur 
> only if
>     the running task blocks, or if it re-enables preemption.
> 
> So it clearly states that a non-preemtible task may block (and 
> rescheduling occurs in
> this case).

Ok, so this is a must fix. Will do. Thanks for reporting.

> 
> Regards,
> Thomas
> 
> 
> 
-- 
Philippe.

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> 
>>Hi Philippe
>>
>>
>>>>non-preemptive mode.
>>>>With original pSOS this was allowed and "non-preemptive" meant that a
>>>>runnable task cannot be preempted by other tasks but can block itself.
>>>>Why is this different in Xenomai and is it possible to implement the 
>>
>>same
>>
>>>>behaviour in Xenomai core?
>>>>
>>>
>>>Xenomai implements the non-preemptible mode as most RTOSes implement
>>>scheduling locks. From this POV, allowing a non-preemptible task to
>>>block makes no sense, and doing so usually either locks up the board, or
>>>causes an API error.
>>>
>>>It could be possible to switch the preemption bit on before entering a
>>>blocking state only for pSOS tasks, then reinstate it when the task
>>>wakes up, though. However, before going down that path, is there any
>>>pSOS documentation that clearly states that such behaviour is to be
>>>expected (i.e. that blocking calls _may_ be called in non-preemptible
>>>mode)?
>>>
>>>Or did you benefit from an undocumented and fortunate side-effect of the
>>>pSOS implementation when relying on such behaviour?
>>
>>Since Markus has already left, I had a quick look in the pSOS System 
>>Concepts Manual:
>>
>>    Each task has a mode word, with two settable bits that can affect 
>>scheduling.
>>    One bit controls the task's preemptibility. If disabled, then once the 
>>task
>>    enters the running state, it will stay running even if other tasks
>>    of higher priority enter the ready state. A task switch will occur 
>>only if
>>    the running task blocks, or if it re-enables preemption.
>>
>>So it clearly states that a non-preemtible task may block (and 
>>rescheduling occurs in
>>this case).
> 
> 
> Ok, so this is a must fix. Will do. Thanks for reporting.

I had a look at the OSEK specification, it also has non-preemptible
tasks. So, I guess we should add an xnpod_locked_schedule that simply does

if (xnthread_test_state(xnpod_current_sched()->runthread, XNLOCK)) {
	xnpod_unlock_sched();
	xnpod_lock_sched();
} else
	xnpod_schedule();

and call this xnpod_locked_schedule() instead of xnpod_schedule() in
these skins.




-- 
                                                 Gilles Chanteperdrix

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Philippe Gerum]

On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> > 
> >>Hi Philippe
> >>
> >>
> >>>>non-preemptive mode.
> >>>>With original pSOS this was allowed and "non-preemptive" meant that a
> >>>>runnable task cannot be preempted by other tasks but can block itself.
> >>>>Why is this different in Xenomai and is it possible to implement the 
> >>
> >>same
> >>
> >>>>behaviour in Xenomai core?
> >>>>
> >>>
> >>>Xenomai implements the non-preemptible mode as most RTOSes implement
> >>>scheduling locks. From this POV, allowing a non-preemptible task to
> >>>block makes no sense, and doing so usually either locks up the board, or
> >>>causes an API error.
> >>>
> >>>It could be possible to switch the preemption bit on before entering a
> >>>blocking state only for pSOS tasks, then reinstate it when the task
> >>>wakes up, though. However, before going down that path, is there any
> >>>pSOS documentation that clearly states that such behaviour is to be
> >>>expected (i.e. that blocking calls _may_ be called in non-preemptible
> >>>mode)?
> >>>
> >>>Or did you benefit from an undocumented and fortunate side-effect of the
> >>>pSOS implementation when relying on such behaviour?
> >>
> >>Since Markus has already left, I had a quick look in the pSOS System 
> >>Concepts Manual:
> >>
> >>    Each task has a mode word, with two settable bits that can affect 
> >>scheduling.
> >>    One bit controls the task's preemptibility. If disabled, then once the 
> >>task
> >>    enters the running state, it will stay running even if other tasks
> >>    of higher priority enter the ready state. A task switch will occur 
> >>only if
> >>    the running task blocks, or if it re-enables preemption.
> >>
> >>So it clearly states that a non-preemtible task may block (and 
> >>rescheduling occurs in
> >>this case).
> > 
> > 
> > Ok, so this is a must fix. Will do. Thanks for reporting.
> 
> I had a look at the OSEK specification, it also has non-preemptible
> tasks. So, I guess we should add an xnpod_locked_schedule that simply does
> 
> if (xnthread_test_state(xnpod_current_sched()->runthread, XNLOCK)) {
> 	xnpod_unlock_sched();
> 	xnpod_lock_sched();
> } else
> 	xnpod_schedule();
> 
> and call this xnpod_locked_schedule() instead of xnpod_schedule() in
> these skins.

Ack, would do. Thomas, could you confirm that the preemptible bit is
raised again for the task when it is scheduled back in?

> 
> 
> 
> 
-- 
Philippe.

[Xenomai-core] Xenomai Bits on MIPS

[somshekar kadam]

Hi All, 

  I am porting Xenomai on MIPS, I am beginner o
Xenomai, please help me in understanding this point. 

whats the purpose of bits directory in include
directory, please throw some light on this, I see it
for 64 bit adoption , correct me if am wrong, what are
the depedency of it on xenomai. 

Please comment. 

Thanks And Regards
Neelu




		
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

Re: [Xenomai-core] Xenomai Bits on MIPS

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

somshekar kadam wrote:
> Hi All, 
> 
>   I am porting Xenomai on MIPS, I am beginner o
> Xenomai, please help me in understanding this point. 
> 
> whats the purpose of bits directory in include
> directory, please throw some light on this, I see it
> for 64 bit adoption , correct me if am wrong, what are
> the depedency of it on xenomai. 
> 
> Please comment. 

Yes, but first on the netiquette:

 o Please don't reply to arbitrary threads when starting a new one, it
   confuses people's mail clients.

 o Please don't put arbitrary people in CC when starting a new thread.

Now on the bits directory: It contains arch-dependent internal helper
functions of the related nucleus core modules. Check them carefully for
potential adoptions that might be required on MIPS.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Philippe Gerum]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> > 
> >>So it clearly states that a non-preemtible task may block (and 
> >>rescheduling occurs in
> >>this case).
> > 
> > 
> > Ok, so this is a must fix. Will do. Thanks for reporting.
> 
> I had a look at the OSEK specification, it also has non-preemptible
> tasks. So, I guess we should add an xnpod_locked_schedule that simply does
> 
> if (xnthread_test_state(xnpod_current_sched()->runthread, XNLOCK)) {
> 	xnpod_unlock_sched();
> 	xnpod_lock_sched();
> } else
> 	xnpod_schedule();
> 
> and call this xnpod_locked_schedule() instead of xnpod_schedule() in
> these skins.

The more I think of it, the more it becomes obvious that the current
implementation of the scheduler locks is uselessly restrictive.
Actually, the only thing we gain from not allowing threads to block
while holding such kind of lock is the opportunity to panic at best if
the debug switch is on, or to go south badly if not.

Even the pattern above would not solve the issue in fact, because things
like xnsynch_sleep_on() which fire a rescheduling call would have to
either get a special argument telling us about the policy in this
matter, or forcibly unlock the scheduler behind the curtains before
calling xnpod_suspend() internally. While we are at it, we would be
better off incorporating the latter at the core, and assume that
callers/skins that do _not_ want to allow sleeping schedlocks did the
proper sanity checks to prevent this before running the rescheduling
procedure. Other would just benefit from the feature.

In short, the following patch against 2.3.0 stock fixes the issue,
allowing threads to block while holding the scheduler lock. 

-- 
Philippe.


[-- Attachment #2: allow-sleeping-schedlock.patch --]
[-- Type: text/x-patch, Size: 8208 bytes --]

Index: include/nucleus/thread.h
===================================================================
--- include/nucleus/thread.h	(revision 2090)
+++ include/nucleus/thread.h	(working copy)
@@ -152,6 +152,8 @@
 
     int cprio;			/* Current priority */
 
+    u_long schedlck;		/*!< Scheduler lock count. */
+
     xnpholder_t rlink;		/* Thread holder in ready queue */
 
     xnpholder_t plink;		/* Thread holder in synchronization queue(s) */
@@ -248,6 +250,7 @@
 #define xnthread_test_info(thread,flags)   testbits((thread)->info,flags)
 #define xnthread_set_info(thread,flags)    __setbits((thread)->info,flags)
 #define xnthread_clear_info(thread,flags)  __clrbits((thread)->info,flags)
+#define xnthread_lock_count(thread)        ((thread)->schedlck)
 #define xnthread_initial_priority(thread) ((thread)->iprio)
 #define xnthread_base_priority(thread)     ((thread)->bprio)
 #define xnthread_current_priority(thread) ((thread)->cprio)
Index: include/nucleus/pod.h
===================================================================
--- include/nucleus/pod.h	(revision 2090)
+++ include/nucleus/pod.h	(working copy)
@@ -203,8 +203,6 @@
 	xnqueue_t threadq;	/*!< All existing threads. */
 	int threadq_rev;	/*!< Modification counter of threadq. */
 
-	volatile u_long schedlck;	/*!< Scheduler lock count. */
-
 	xnqueue_t tstartq,	/*!< Thread start hook queue. */
 	 tswitchq,		/*!< Thread switch hook queue. */
 	 tdeleteq;		/*!< Thread delete hook queue. */
@@ -348,7 +346,7 @@
     (!!xnthread_test_state(xnpod_current_thread(),XNLOCK))
 
 #define xnpod_unblockable_p() \
-    (xnpod_asynch_p() || xnthread_test_state(xnpod_current_thread(),XNLOCK|XNROOT))
+    (xnpod_asynch_p() || xnthread_test_state(xnpod_current_thread(),XNROOT))
 
 #define xnpod_root_p() \
     (!!xnthread_test_state(xnpod_current_thread(),XNROOT))
@@ -445,24 +443,26 @@
 
 static inline void xnpod_lock_sched(void)
 {
+	xnthread_t *runthread = xnpod_current_sched()->runthread;
 	spl_t s;
 
 	xnlock_get_irqsave(&nklock, s);
 
-	if (nkpod->schedlck++ == 0)
-		xnthread_set_state(xnpod_current_sched()->runthread, XNLOCK);
+	if (xnthread_lock_count(runthread)++ == 0)
+		xnthread_set_state(runthread, XNLOCK);
 
 	xnlock_put_irqrestore(&nklock, s);
 }
 
 static inline void xnpod_unlock_sched(void)
 {
+	xnthread_t *runthread = xnpod_current_sched()->runthread;
 	spl_t s;
 
 	xnlock_get_irqsave(&nklock, s);
 
-	if (--nkpod->schedlck == 0) {
-		xnthread_clear_state(xnpod_current_sched()->runthread, XNLOCK);
+	if (--xnthread_lock_count(runthread) == 0) {
+		xnthread_clear_state(runthread, XNLOCK);
 		xnpod_schedule();
 	}
 
Index: ChangeLog
===================================================================
--- ChangeLog	(revision 2091)
+++ ChangeLog	(working copy)
@@ -1,5 +1,9 @@
 2007-01-30  Philippe Gerum  <rpm@xenomai.org>
 
+	* ksrc/nucleus/pod.c (xnpod_schedule): Allow threads to block
+	while holding the scheduler lock. Move the lock nesting count as a
+	per-thread data (instead of the former global pod attribute).
+
 	* sim/include/Makefile.am: Fix destination directory for
 	xeno_config.h to $(prefix)/asm-sim.
 
Index: ksrc/nucleus/thread.c
===================================================================
--- ksrc/nucleus/thread.c	(revision 2090)
+++ ksrc/nucleus/thread.c	(working copy)
@@ -69,6 +69,7 @@
 
 	thread->state = flags;
 	thread->info = 0;
+	thread->schedlck = 0;
 	thread->signals = 0;
 	thread->asrmode = 0;
 	thread->asrimask = 0;
Index: ksrc/nucleus/pod.c
===================================================================
--- ksrc/nucleus/pod.c	(revision 2090)
+++ ksrc/nucleus/pod.c	(working copy)
@@ -360,7 +360,6 @@
 	initq(&pod->tswitchq);
 	initq(&pod->tdeleteq);
 
-	pod->schedlck = 0;
 	pod->minpri = minpri;
 	pod->maxpri = maxpri;
 	pod->jiffies = 0;
@@ -854,7 +853,9 @@
  *
  * - XNLOCK causes the thread to lock the scheduler when it starts.
  * The target thread will have to call the xnpod_unlock_sched()
- * service to unlock the scheduler.
+ * service to unlock the scheduler. A non-preemptible thread may still
+ * block, in which case, the lock is reasserted when the thread is
+ * scheduled back in.
  *
  * - XNRRB causes the thread to be marked as undergoing the
  * round-robin scheduling policy at startup.  The contents of the
@@ -1061,7 +1062,7 @@
 		/* Clear all sched locks held by the restarted thread. */
 		if (xnthread_test_state(thread, XNLOCK)) {
 			xnthread_clear_state(thread, XNLOCK);
-			nkpod->schedlck = 0;
+			xnthread_lock_count(thread) = 0;
 		}
 
 		xnthread_set_state(thread, XNRESTART);
@@ -1101,7 +1102,9 @@
  *
  * - XNLOCK causes the thread to lock the scheduler.  The target
  * thread will have to call the xnpod_unlock_sched() service to unlock
- * the scheduler or clear the XNLOCK bit forcibly using this service.
+ * the scheduler or clear the XNLOCK bit forcibly using this
+ * service. A non-preemptible thread may still block, in which case,
+ * the lock is reasserted when the thread is scheduled back in.
  *
  * - XNRRB causes the thread to be marked as undergoing the
  * round-robin scheduling policy.  The contents of the thread.rrperiod
@@ -1164,7 +1167,7 @@
 				/* Actually grab the scheduler lock. */
 				xnpod_lock_sched();
 		} else if (!xnthread_test_state(thread, XNLOCK))
-			nkpod->schedlck = 0;
+			xnthread_lock_count(thread) = 0;
 	}
 
 	if (!(oldmode & XNRRB) && xnthread_test_state(thread, XNRRB))
@@ -1249,14 +1252,6 @@
 
 	xntimer_stop(&thread->ptimer);
 
-	/* Ensure the rescheduling can take place if the deleted thread is
-	   the running one. */
-
-	if (xnthread_test_state(thread, XNLOCK)) {
-		xnthread_clear_state(thread, XNLOCK);
-		nkpod->schedlck = 0;
-	}
-
 	if (xnthread_test_state(thread, XNPEND))
 		xnsynch_forget_sleeper(thread);
 
@@ -1385,15 +1380,8 @@
 
 	sched = thread->sched;
 
-	if (thread == sched->runthread) {
-#if XENO_DEBUG(NUCLEUS) || defined(__XENO_SIM__)
-		if (sched == xnpod_current_sched() && xnpod_locked_p())
-			xnpod_fatal
-			    ("suspensive call issued while the scheduler was locked");
-#endif /* XENO_DEBUG(NUCLEUS) || __XENO_SIM__ */
-
+	if (thread == sched->runthread)
 		xnsched_set_resched(sched);
-	}
 
 	/* We must make sure that we don't clear the wait channel if a
 	   thread is first blocked (wchan != NULL) then forcibly suspended
@@ -2288,9 +2276,10 @@
  * therefore the caller does not need to explicitely issue
  * xnpod_schedule() after such operations.
  *
- * The rescheduling procedure always leads to a null-effect if the
- * scheduler is locked (XNLOCK bit set in the status mask of the
- * running thread), or if it is called on behalf of an ISR or callout.
+ * The rescheduling procedure always leads to a null-effect if it is
+ * called on behalf of an ISR or callout. Any outstanding scheduler
+ * lock held by the outgoing thread will be restored when the thread
+ * is scheduled back in.
  *
  * Calling this procedure with no applicable context switch pending is
  * harmless and simply leads to a null-effect.
@@ -2319,6 +2308,7 @@
 void xnpod_schedule(void)
 {
 	xnthread_t *threadout, *threadin, *runthread;
+	xnpholder_t *pholder;
 	xnsched_t *sched;
 #if defined(CONFIG_SMP) || XENO_DEBUG(NUCLEUS)
 	int need_resched;
@@ -2373,19 +2363,19 @@
 
 #endif /* CONFIG_SMP */
 
-	if (xnthread_test_state(runthread, XNLOCK))
-		/* The running thread has locked the scheduler and is still
-		   ready to run. Just check for (self-posted) pending signals,
-		   then exit the procedure without actually switching
-		   contexts. */
-		goto signal_unlock_and_exit;
-
 	/* Clear the rescheduling bit */
 	xnsched_clr_resched(sched);
 
 	if (!xnthread_test_state(runthread, XNTHREAD_BLOCK_BITS | XNZOMBIE)) {
-		xnpholder_t *pholder = sched_getheadpq(&sched->readyq);
 
+		/* Do not preempt the current thread if it holds the
+		 * scheduler lock. */
+
+		if (xnthread_test_state(runthread, XNLOCK))
+			goto signal_unlock_and_exit;
+
+		pholder = sched_getheadpq(&sched->readyq);
+
 		if (pholder) {
 			xnthread_t *head = link2thread(pholder, rlink);
 
@@ -2405,7 +2395,7 @@
 		goto signal_unlock_and_exit;
 	}
 
-      do_switch:
+     do_switch:
 
 	threadout = runthread;
 	threadin = link2thread(sched_getpq(&sched->readyq), rlink);

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> 
>>Philippe Gerum wrote:
>>
>>>On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
>>>
>>>
>>>>So it clearly states that a non-preemtible task may block (and 
>>>>rescheduling occurs in
>>>>this case).
>>>
>>>
>>>Ok, so this is a must fix. Will do. Thanks for reporting.
>>
>>I had a look at the OSEK specification, it also has non-preemptible
>>tasks. So, I guess we should add an xnpod_locked_schedule that simply does
>>
>>if (xnthread_test_state(xnpod_current_sched()->runthread, XNLOCK)) {
>>	xnpod_unlock_sched();
>>	xnpod_lock_sched();
>>} else
>>	xnpod_schedule();
>>
>>and call this xnpod_locked_schedule() instead of xnpod_schedule() in
>>these skins.
> 
> 
> The more I think of it, the more it becomes obvious that the current
> implementation of the scheduler locks is uselessly restrictive.
> Actually, the only thing we gain from not allowing threads to block
> while holding such kind of lock is the opportunity to panic at best if
> the debug switch is on, or to go south badly if not.
> 
> Even the pattern above would not solve the issue in fact, because things
> like xnsynch_sleep_on() which fire a rescheduling call would have to
> either get a special argument telling us about the policy in this
> matter, or forcibly unlock the scheduler behind the curtains before
> calling xnpod_suspend() internally. While we are at it, we would be
> better off incorporating the latter at the core, and assume that
> callers/skins that do _not_ want to allow sleeping schedlocks did the
> proper sanity checks to prevent this before running the rescheduling
> procedure. Other would just benefit from the feature.
> 
> In short, the following patch against 2.3.0 stock fixes the issue,
> allowing threads to block while holding the scheduler lock. 

Ok, but this means that the skins which use XNLOCK with the previous
meaning need fixing.

-- 
                                                 Gilles Chanteperdrix

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Philippe Gerum]

On Wed, 2007-01-31 at 09:55 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> > 
> >>Philippe Gerum wrote:
> >>
> >>>On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> >>>
> >>>
> >>>>So it clearly states that a non-preemtible task may block (and 
> >>>>rescheduling occurs in
> >>>>this case).
> >>>
> >>>
> >>>Ok, so this is a must fix. Will do. Thanks for reporting.
> >>
> >>I had a look at the OSEK specification, it also has non-preemptible
> >>tasks. So, I guess we should add an xnpod_locked_schedule that simply does
> >>
> >>if (xnthread_test_state(xnpod_current_sched()->runthread, XNLOCK)) {
> >>	xnpod_unlock_sched();
> >>	xnpod_lock_sched();
> >>} else
> >>	xnpod_schedule();
> >>
> >>and call this xnpod_locked_schedule() instead of xnpod_schedule() in
> >>these skins.
> > 
> > 
> > The more I think of it, the more it becomes obvious that the current
> > implementation of the scheduler locks is uselessly restrictive.
> > Actually, the only thing we gain from not allowing threads to block
> > while holding such kind of lock is the opportunity to panic at best if
> > the debug switch is on, or to go south badly if not.
> > 
> > Even the pattern above would not solve the issue in fact, because things
> > like xnsynch_sleep_on() which fire a rescheduling call would have to
> > either get a special argument telling us about the policy in this
> > matter, or forcibly unlock the scheduler behind the curtains before
> > calling xnpod_suspend() internally. While we are at it, we would be
> > better off incorporating the latter at the core, and assume that
> > callers/skins that do _not_ want to allow sleeping schedlocks did the
> > proper sanity checks to prevent this before running the rescheduling
> > procedure. Other would just benefit from the feature.
> > 
> > In short, the following patch against 2.3.0 stock fixes the issue,
> > allowing threads to block while holding the scheduler lock. 
> 
> Ok, but this means that the skins which use XNLOCK with the previous
> meaning need fixing.
> 

Only those which really wanted - i.e. by design - to return an error
flag (or the board to lockup or panic) in case of a thread going to
sleep while holding the schedlock. This change does not affect the
schedlock semantics otherwise.

-- 
Philippe.

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Gilles Chanteperdrix]

Philippe Gerum wrote:
>>>In short, the following patch against 2.3.0 stock fixes the issue,
>>>allowing threads to block while holding the scheduler lock. 
>>
>>Ok, but this means that the skins which use XNLOCK with the previous
>>meaning need fixing.
>>
> 
> 
> Only those which really wanted - i.e. by design - to return an error
> flag (or the board to lockup or panic) in case of a thread going to
> sleep while holding the schedlock. This change does not affect the
> schedlock semantics otherwise.
> 

I do not understand how it works, I mean, how do you know, in
xnpod_schedule, if xnpod_schedule was voluntarily called by the current
thread, or was called upon reception of an interruption ?

-- 
                                                 Gilles Chanteperdrix

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Philippe Gerum]

On Wed, 2007-01-31 at 10:28 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> >>>In short, the following patch against 2.3.0 stock fixes the issue,
> >>>allowing threads to block while holding the scheduler lock. 
> >>
> >>Ok, but this means that the skins which use XNLOCK with the previous
> >>meaning need fixing.
> >>
> > 
> > 
> > Only those which really wanted - i.e. by design - to return an error
> > flag (or the board to lockup or panic) in case of a thread going to
> > sleep while holding the schedlock. This change does not affect the
> > schedlock semantics otherwise.
> > 
> 
> I do not understand how it works, I mean, how do you know, in
> xnpod_schedule, if xnpod_schedule was voluntarily called by the current
> thread, or was called upon reception of an interruption ?
> 

You don't have to care about this issue. Is the current thread
preemptable when considering the scheduling state is the right issue to
care of, and the answer is that such thread must not be blocked at the
time the XNLOCK bit is checked. It turns out that checking for
preemptability in xnpod_schedule() only when the current thread has no
blocking bits armed is enough (this test from xnpod_schedule() has moved
compared to the previous implementation). Now, if the current thread
enters xnpod_schedule() with some blocking bits set into its state mask,
then the test for preemptability is bypassed and the rescheduling takes
place as usual, which gives us sleeping schedlocks. Since the formerly
global schedlock nesting count has been moved to the per-thread TCB,
there is no need for explicit save/restore of such information either.

In any case, if the current thread has locked the scheduler and is still
in a ready-to-run state, you don't want anyone to be able to switch it
out, be it ISR or thread. ISRs could still call xnpod_suspend() against
the current thread though and force it out when returning from the outer
interrupt frame by a call to xnpod_schedule(), which is ok, and if you
think of it, much saner than the former implementation that would deny
_any_ rescheduling of a thread which happened to be suspended from the
current interrupt context. Too bad for emergency measures.

-- 
Philippe.

Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>>>> In short, the following patch against 2.3.0 stock fixes the issue,
>>>> allowing threads to block while holding the scheduler lock. 
>>> Ok, but this means that the skins which use XNLOCK with the previous
>>> meaning need fixing.
>>>
>>
>> Only those which really wanted - i.e. by design - to return an error
>> flag (or the board to lockup or panic) in case of a thread going to
>> sleep while holding the schedlock. This change does not affect the
>> schedlock semantics otherwise.
>>
> 
> I do not understand how it works, I mean, how do you know, in
> xnpod_schedule, if xnpod_schedule was voluntarily called by the current
> thread, or was called upon reception of an interruption ?

sched->inesting manages the scheduler lock in interrupt context (and
XNLOCK requires Xenomai thread context anyway - something an interrupt
handler cannot expect). So that part is not affected by the XNLOCK changes.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]