[Xenomai] Xenomai-forge pSOS t_start followed by t_suspend does not work

[Xenomai] Xenomai-forge pSOS t_start followed by t_suspend does not work

[Kim De Mey]

Hi,

I believe there is a problem in Xenomai-forge when doing a pSOS
t_suspend() call right after a t_start() call.
It looks like the task does not get suspended in some cases. The
return value of t_suspend() is 0 however.

I suspect that this happens when the threadobj_prologue() is not
finished yet at the moment that the notifier_sighandler() is called.
In this case it could be that the notifier_init() did not run yet. If
this is the case, then the notifier_sighandler() will not do any
notifier callback and thus the task will not be suspended. Additional
t_suspend() calls will not work as the "notified" flag has been set
already.
Is this possible?

If I enable debug (--enable-debug), then sometimes the assertion in
the notifier_callback() occurs. I think this might happen if the
notifier_init() has run already however the threadobj_set_current()
has not yet before the callback is run. I am unsure if this case
causes any actual problems.

It is difficult to debug all this with GDB as when I do so, the
notifier_sighandler() runs very often on the wrong thread. This then
causes the owner check in the notifier_sighandler() to fail. I don't
know why it behaves like this when being debugged but that is probably
a GDB thing.

Thanks in advance for any help!

Regards,
Kim

Re: [Xenomai] Xenomai-forge pSOS t_start followed by t_suspend does not work

[Kim De Mey]

2014-02-10 12:23 GMT+01:00 Kim De Mey <kim.demey@gmail.com>:
> 2014-02-09 17:57 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>> On 02/06/2014 02:36 PM, Kim De Mey wrote:
>>>
>>> Hi,
>>>
>>> I believe there is a problem in Xenomai-forge when doing a pSOS
>>> t_suspend() call right after a t_start() call.
>>> It looks like the task does not get suspended in some cases. The
>>> return value of t_suspend() is 0 however.
>>>
>>> I suspect that this happens when the threadobj_prologue() is not
>>> finished yet at the moment that the notifier_sighandler() is called.
>>> In this case it could be that the notifier_init() did not run yet. If
>>> this is the case, then the notifier_sighandler() will not do any
>>> notifier callback and thus the task will not be suspended. Additional
>>> t_suspend() calls will not work as the "notified" flag has been set
>>> already.
>>> Is this possible?
>>>
>>
>> Unfortunately, yes.
>>
>> This is a general issue in the current implementation, as any child thread
>> created by the emulation sub-system might not have fully registered before
>> the parent refers to it due to priority/wait state issues.
>>
>> We definitely need stronger handshaking there, could you please check again
>> with this changes in?
>> http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=a48b8f640cad510a1101e380cc54ef2bf29afcd6
>>
>> TIA,
>>
>
> I tested the new revision and the problems no longer occur. So it looks good!
>
> Many thanks for fixing this so quickly.
>

Hi Philippe,

I'm afraid the new handshaking mechanism introduced to fix the
problems I was having created an actually worse problem.

If now a parent task with high priority creates a child task with low
priority while there is another task with medium priority creating a
high load on the CPU then the parent task gets stuck in the creation
of the child. This while the parent task has a higher priority than
the task creating the load.

I believe it is due to the fact that the parent task now waits for a
sem_post of the child, which in this case has a too low priority to
get this done.

Should the child priority be temporary increased to the one of the
parent during the creation or would that be a bad idea?

Regards,
Kim

Re: [Xenomai] Xenomai-forge pSOS t_start followed by t_suspend does not work

[Philippe Gerum]

On 02/26/2014 09:54 AM, Kim De Mey wrote:
> 2014-02-10 12:23 GMT+01:00 Kim De Mey <kim.demey@gmail.com>:
>> 2014-02-09 17:57 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>> On 02/06/2014 02:36 PM, Kim De Mey wrote:
>>>>
>>>> Hi,
>>>>
>>>> I believe there is a problem in Xenomai-forge when doing a pSOS
>>>> t_suspend() call right after a t_start() call.
>>>> It looks like the task does not get suspended in some cases. The
>>>> return value of t_suspend() is 0 however.
>>>>
>>>> I suspect that this happens when the threadobj_prologue() is not
>>>> finished yet at the moment that the notifier_sighandler() is called.
>>>> In this case it could be that the notifier_init() did not run yet. If
>>>> this is the case, then the notifier_sighandler() will not do any
>>>> notifier callback and thus the task will not be suspended. Additional
>>>> t_suspend() calls will not work as the "notified" flag has been set
>>>> already.
>>>> Is this possible?
>>>>
>>>
>>> Unfortunately, yes.
>>>
>>> This is a general issue in the current implementation, as any child thread
>>> created by the emulation sub-system might not have fully registered before
>>> the parent refers to it due to priority/wait state issues.
>>>
>>> We definitely need stronger handshaking there, could you please check again
>>> with this changes in?
>>> http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=a48b8f640cad510a1101e380cc54ef2bf29afcd6
>>>
>>> TIA,
>>>
>>
>> I tested the new revision and the problems no longer occur. So it looks good!
>>
>> Many thanks for fixing this so quickly.
>>
>
> Hi Philippe,
>
> I'm afraid the new handshaking mechanism introduced to fix the
> problems I was having created an actually worse problem.
>
> If now a parent task with high priority creates a child task with low
> priority while there is another task with medium priority creating a
> high load on the CPU then the parent task gets stuck in the creation
> of the child. This while the parent task has a higher priority than
> the task creating the load.
>
> I believe it is due to the fact that the parent task now waits for a
> sem_post of the child, which in this case has a too low priority to
> get this done.
>
> Should the child priority be temporary increased to the one of the
> parent during the creation or would that be a bad idea?
>

I don't see any other option for preventing this priority inversion 
anyway, since the child prologue is logically part of the parent context 
actually. IOW, the child has to fully inherit the scheduling parameters 
of the parent until its prologue is over. Ok, will do this.

-- 
Philippe.

Re: [Xenomai] Xenomai-forge pSOS t_start followed by t_suspend does not work

[Philippe Gerum]

On 02/28/2014 02:30 PM, Philippe Gerum wrote:
> On 02/26/2014 09:54 AM, Kim De Mey wrote:
>> 2014-02-10 12:23 GMT+01:00 Kim De Mey <kim.demey@gmail.com>:
>>> 2014-02-09 17:57 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>> On 02/06/2014 02:36 PM, Kim De Mey wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I believe there is a problem in Xenomai-forge when doing a pSOS
>>>>> t_suspend() call right after a t_start() call.
>>>>> It looks like the task does not get suspended in some cases. The
>>>>> return value of t_suspend() is 0 however.
>>>>>
>>>>> I suspect that this happens when the threadobj_prologue() is not
>>>>> finished yet at the moment that the notifier_sighandler() is called.
>>>>> In this case it could be that the notifier_init() did not run yet. If
>>>>> this is the case, then the notifier_sighandler() will not do any
>>>>> notifier callback and thus the task will not be suspended. Additional
>>>>> t_suspend() calls will not work as the "notified" flag has been set
>>>>> already.
>>>>> Is this possible?
>>>>>
>>>>
>>>> Unfortunately, yes.
>>>>
>>>> This is a general issue in the current implementation, as any child 
>>>> thread
>>>> created by the emulation sub-system might not have fully registered 
>>>> before
>>>> the parent refers to it due to priority/wait state issues.
>>>>
>>>> We definitely need stronger handshaking there, could you please 
>>>> check again
>>>> with this changes in?
>>>> http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=a48b8f640cad510a1101e380cc54ef2bf29afcd6 
>>>>
>>>>
>>>> TIA,
>>>>
>>>
>>> I tested the new revision and the problems no longer occur. So it 
>>> looks good!
>>>
>>> Many thanks for fixing this so quickly.
>>>
>>
>> Hi Philippe,
>>
>> I'm afraid the new handshaking mechanism introduced to fix the
>> problems I was having created an actually worse problem.
>>
>> If now a parent task with high priority creates a child task with low
>> priority while there is another task with medium priority creating a
>> high load on the CPU then the parent task gets stuck in the creation
>> of the child. This while the parent task has a higher priority than
>> the task creating the load.
>>
>> I believe it is due to the fact that the parent task now waits for a
>> sem_post of the child, which in this case has a too low priority to
>> get this done.
>>
>> Should the child priority be temporary increased to the one of the
>> parent during the creation or would that be a bad idea?
>>
> 
> I don't see any other option for preventing this priority inversion 
> anyway, since the child prologue is logically part of the parent context 
> actually. IOW, the child has to fully inherit the scheduling parameters 
> of the parent until its prologue is over. Ok, will do this.
> 

Does this patch helps with your test case?

diff --git a/lib/copperplate/internal.c b/lib/copperplate/internal.c
index a7f86e7..86e69af 100644
--- a/lib/copperplate/internal.c
+++ b/lib/copperplate/internal.c
@@ -68,10 +68,9 @@ int copperplate_probe_node(unsigned int id)
 int copperplate_create_thread(struct corethread_attributes *cta,
 			      pthread_t *tid)
 {
-	struct sched_param_ex param_ex;
 	pthread_attr_ex_t attr_ex;
 	size_t stacksize;
-	int policy, ret;
+	int ret;
 
 	ret = thread_spawn_prologue(cta);
 	if (ret)
@@ -81,12 +80,8 @@ int copperplate_create_thread(struct corethread_attributes *cta,
 	if (stacksize < PTHREAD_STACK_MIN * 4)
 		stacksize = PTHREAD_STACK_MIN * 4;
 
-	param_ex.sched_priority = cta->prio;
-	policy = cta->prio ? SCHED_RT : SCHED_OTHER;
 	pthread_attr_init_ex(&attr_ex);
-	pthread_attr_setinheritsched_ex(&attr_ex, PTHREAD_EXPLICIT_SCHED);
-	pthread_attr_setschedpolicy_ex(&attr_ex, policy);
-	pthread_attr_setschedparam_ex(&attr_ex, &param_ex);
+	pthread_attr_setinheritsched_ex(&attr_ex, PTHREAD_INHERIT_SCHED);
 	pthread_attr_setstacksize_ex(&attr_ex, stacksize);
 	pthread_attr_setdetachstate_ex(&attr_ex, cta->detachstate);
 	ret = __bt(-pthread_create_ex(tid, &attr_ex, thread_trampoline, cta));
@@ -120,6 +115,11 @@ static inline void prepare_wait_corespec(void)
 	cobalt_thread_harden();
 }
 
+static inline int finish_wait_corespec(struct corethread_attributes *cta)
+{
+	return __bt(copperplate_renice_thread(pthread_self(), cta->prio));
+}
+
 #else /* CONFIG_XENO_MERCURY */
 
 int copperplate_probe_node(unsigned int id)
@@ -130,10 +130,9 @@ int copperplate_probe_node(unsigned int id)
 int copperplate_create_thread(struct corethread_attributes *cta,
 			      pthread_t *tid)
 {
-	struct sched_param param;
 	pthread_attr_t attr;
 	size_t stacksize;
-	int policy, ret;
+	int ret;
 
 	ret = thread_spawn_prologue(cta);
 	if (ret)
@@ -143,12 +142,8 @@ int copperplate_create_thread(struct corethread_attributes *cta,
 	if (stacksize < PTHREAD_STACK_MIN * 4)
 		stacksize = PTHREAD_STACK_MIN * 4;
 
-	param.sched_priority = cta->prio;
-	policy = cta->prio ? SCHED_RT : SCHED_OTHER;
 	pthread_attr_init(&attr);
-	pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
-	pthread_attr_setschedpolicy(&attr, policy);
-	pthread_attr_setschedparam(&attr, &param);
+	pthread_attr_setinheritsched(&attr, PTHREAD_INHERIT_SCHED);
 	pthread_attr_setstacksize(&attr, stacksize);
 	pthread_attr_setdetachstate(&attr, cta->detachstate);
 	ret = __bt(-pthread_create(tid, &attr, thread_trampoline, cta));
@@ -176,6 +171,11 @@ static inline void prepare_wait_corespec(void)
 	/* empty */
 }
 
+static inline int finish_wait_corespec(struct corethread_attributes *cta)
+{
+	return __bt(copperplate_renice_thread(pthread_self(), cta->prio));
+}
+
 #endif  /* CONFIG_XENO_MERCURY */
 
 static int thread_spawn_prologue(struct corethread_attributes *cta)
@@ -208,19 +208,17 @@ static void thread_spawn_wait(sem_t *sem)
 
 static void *thread_trampoline(void *arg)
 {
-	struct corethread_attributes *cta = arg;
-	void *__arg, *(*__run)(void *arg);
+	struct corethread_attributes *cta = arg, _cta;
 	sem_t released;
 	int ret;
 
 	/*
 	 * cta may be on the parent's stack, so it may be dandling
-	 * soon after the parent is posted: copy what we need from
-	 * this area early on.
+	 * soon after the parent is posted: copy this argument
+	 * structure early on.
 	 */
-	__run = cta->run;
-	__arg = cta->arg;
-	ret = cta->prologue(__arg);
+	_cta = *cta;
+	ret = cta->prologue(cta->arg);
 	cta->__reserved.status = ret;
 
 	if (ret) {
@@ -238,12 +236,13 @@ static void *thread_trampoline(void *arg)
 	 */
 	prepare_wait_corespec();
 	__RT(sem_post(&cta->__reserved.warm));
-
 	thread_spawn_wait(&released);
-
 	__RT(sem_destroy(&released));
+	ret = finish_wait_corespec(&_cta);
+	if (ret)
+		warning("core thread prologue failed, %s", symerror(ret));
 
-	return __run(__arg);
+	return _cta.run(_cta.arg);
 }
 
 static int thread_spawn_epilogue(struct corethread_attributes *cta)


-- 
Philippe.

Re: [Xenomai] Xenomai-forge pSOS t_start followed by t_suspend does not work

[Kim De Mey]

2014-02-28 15:02 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
> On 02/28/2014 02:30 PM, Philippe Gerum wrote:
>> On 02/26/2014 09:54 AM, Kim De Mey wrote:
>>> 2014-02-10 12:23 GMT+01:00 Kim De Mey <kim.demey@gmail.com>:
>>>> 2014-02-09 17:57 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>> On 02/06/2014 02:36 PM, Kim De Mey wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I believe there is a problem in Xenomai-forge when doing a pSOS
>>>>>> t_suspend() call right after a t_start() call.
>>>>>> It looks like the task does not get suspended in some cases. The
>>>>>> return value of t_suspend() is 0 however.
>>>>>>
>>>>>> I suspect that this happens when the threadobj_prologue() is not
>>>>>> finished yet at the moment that the notifier_sighandler() is called.
>>>>>> In this case it could be that the notifier_init() did not run yet. If
>>>>>> this is the case, then the notifier_sighandler() will not do any
>>>>>> notifier callback and thus the task will not be suspended. Additional
>>>>>> t_suspend() calls will not work as the "notified" flag has been set
>>>>>> already.
>>>>>> Is this possible?
>>>>>>
>>>>>
>>>>> Unfortunately, yes.
>>>>>
>>>>> This is a general issue in the current implementation, as any child
>>>>> thread
>>>>> created by the emulation sub-system might not have fully registered
>>>>> before
>>>>> the parent refers to it due to priority/wait state issues.
>>>>>
>>>>> We definitely need stronger handshaking there, could you please
>>>>> check again
>>>>> with this changes in?
>>>>> http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=a48b8f640cad510a1101e380cc54ef2bf29afcd6
>>>>>
>>>>>
>>>>> TIA,
>>>>>
>>>>
>>>> I tested the new revision and the problems no longer occur. So it
>>>> looks good!
>>>>
>>>> Many thanks for fixing this so quickly.
>>>>
>>>
>>> Hi Philippe,
>>>
>>> I'm afraid the new handshaking mechanism introduced to fix the
>>> problems I was having created an actually worse problem.
>>>
>>> If now a parent task with high priority creates a child task with low
>>> priority while there is another task with medium priority creating a
>>> high load on the CPU then the parent task gets stuck in the creation
>>> of the child. This while the parent task has a higher priority than
>>> the task creating the load.
>>>
>>> I believe it is due to the fact that the parent task now waits for a
>>> sem_post of the child, which in this case has a too low priority to
>>> get this done.
>>>
>>> Should the child priority be temporary increased to the one of the
>>> parent during the creation or would that be a bad idea?
>>>
>>
>> I don't see any other option for preventing this priority inversion
>> anyway, since the child prologue is logically part of the parent context
>> actually. IOW, the child has to fully inherit the scheduling parameters
>> of the parent until its prologue is over. Ok, will do this.
>>
>
> Does this patch helps with your test case?

Yes, this patch fixes the problem. Test case works and the original
suspend test case also still works.
I will run it over more tests but so far it looks good.

Thanks!

>
> diff --git a/lib/copperplate/internal.c b/lib/copperplate/internal.c
> index a7f86e7..86e69af 100644
> --- a/lib/copperplate/internal.c
> +++ b/lib/copperplate/internal.c
> @@ -68,10 +68,9 @@ int copperplate_probe_node(unsigned int id)
>  int copperplate_create_thread(struct corethread_attributes *cta,
>                               pthread_t *tid)
>  {
> -       struct sched_param_ex param_ex;
>         pthread_attr_ex_t attr_ex;
>         size_t stacksize;
> -       int policy, ret;
> +       int ret;
>
>         ret = thread_spawn_prologue(cta);
>         if (ret)
> @@ -81,12 +80,8 @@ int copperplate_create_thread(struct corethread_attributes *cta,
>         if (stacksize < PTHREAD_STACK_MIN * 4)
>                 stacksize = PTHREAD_STACK_MIN * 4;
>
> -       param_ex.sched_priority = cta->prio;
> -       policy = cta->prio ? SCHED_RT : SCHED_OTHER;
>         pthread_attr_init_ex(&attr_ex);
> -       pthread_attr_setinheritsched_ex(&attr_ex, PTHREAD_EXPLICIT_SCHED);
> -       pthread_attr_setschedpolicy_ex(&attr_ex, policy);
> -       pthread_attr_setschedparam_ex(&attr_ex, &param_ex);
> +       pthread_attr_setinheritsched_ex(&attr_ex, PTHREAD_INHERIT_SCHED);
>         pthread_attr_setstacksize_ex(&attr_ex, stacksize);
>         pthread_attr_setdetachstate_ex(&attr_ex, cta->detachstate);
>         ret = __bt(-pthread_create_ex(tid, &attr_ex, thread_trampoline, cta));
> @@ -120,6 +115,11 @@ static inline void prepare_wait_corespec(void)
>         cobalt_thread_harden();
>  }
>
> +static inline int finish_wait_corespec(struct corethread_attributes *cta)
> +{
> +       return __bt(copperplate_renice_thread(pthread_self(), cta->prio));
> +}
> +
>  #else /* CONFIG_XENO_MERCURY */
>
>  int copperplate_probe_node(unsigned int id)
> @@ -130,10 +130,9 @@ int copperplate_probe_node(unsigned int id)
>  int copperplate_create_thread(struct corethread_attributes *cta,
>                               pthread_t *tid)
>  {
> -       struct sched_param param;
>         pthread_attr_t attr;
>         size_t stacksize;
> -       int policy, ret;
> +       int ret;
>
>         ret = thread_spawn_prologue(cta);
>         if (ret)
> @@ -143,12 +142,8 @@ int copperplate_create_thread(struct corethread_attributes *cta,
>         if (stacksize < PTHREAD_STACK_MIN * 4)
>                 stacksize = PTHREAD_STACK_MIN * 4;
>
> -       param.sched_priority = cta->prio;
> -       policy = cta->prio ? SCHED_RT : SCHED_OTHER;
>         pthread_attr_init(&attr);
> -       pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
> -       pthread_attr_setschedpolicy(&attr, policy);
> -       pthread_attr_setschedparam(&attr, &param);
> +       pthread_attr_setinheritsched(&attr, PTHREAD_INHERIT_SCHED);
>         pthread_attr_setstacksize(&attr, stacksize);
>         pthread_attr_setdetachstate(&attr, cta->detachstate);
>         ret = __bt(-pthread_create(tid, &attr, thread_trampoline, cta));
> @@ -176,6 +171,11 @@ static inline void prepare_wait_corespec(void)
>         /* empty */
>  }
>
> +static inline int finish_wait_corespec(struct corethread_attributes *cta)
> +{
> +       return __bt(copperplate_renice_thread(pthread_self(), cta->prio));
> +}
> +
>  #endif  /* CONFIG_XENO_MERCURY */
>
>  static int thread_spawn_prologue(struct corethread_attributes *cta)
> @@ -208,19 +208,17 @@ static void thread_spawn_wait(sem_t *sem)
>
>  static void *thread_trampoline(void *arg)
>  {
> -       struct corethread_attributes *cta = arg;
> -       void *__arg, *(*__run)(void *arg);
> +       struct corethread_attributes *cta = arg, _cta;
>         sem_t released;
>         int ret;
>
>         /*
>          * cta may be on the parent's stack, so it may be dandling
> -        * soon after the parent is posted: copy what we need from
> -        * this area early on.
> +        * soon after the parent is posted: copy this argument
> +        * structure early on.
>          */
> -       __run = cta->run;
> -       __arg = cta->arg;
> -       ret = cta->prologue(__arg);
> +       _cta = *cta;
> +       ret = cta->prologue(cta->arg);
>         cta->__reserved.status = ret;
>
>         if (ret) {
> @@ -238,12 +236,13 @@ static void *thread_trampoline(void *arg)
>          */
>         prepare_wait_corespec();
>         __RT(sem_post(&cta->__reserved.warm));
> -
>         thread_spawn_wait(&released);
> -
>         __RT(sem_destroy(&released));
> +       ret = finish_wait_corespec(&_cta);
> +       if (ret)
> +               warning("core thread prologue failed, %s", symerror(ret));
>
> -       return __run(__arg);
> +       return _cta.run(_cta.arg);
>  }
>
>  static int thread_spawn_epilogue(struct corethread_attributes *cta)
>
>
> --
> Philippe.

Re: [Xenomai] Xenomai-forge pSOS t_start followed by t_suspend does not work

[Philippe Gerum]

On 02/28/2014 03:35 PM, Kim De Mey wrote:
> 2014-02-28 15:02 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>> On 02/28/2014 02:30 PM, Philippe Gerum wrote:
>>> On 02/26/2014 09:54 AM, Kim De Mey wrote:
>>>> 2014-02-10 12:23 GMT+01:00 Kim De Mey <kim.demey@gmail.com>:
>>>>> 2014-02-09 17:57 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>> On 02/06/2014 02:36 PM, Kim De Mey wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I believe there is a problem in Xenomai-forge when doing a pSOS
>>>>>>> t_suspend() call right after a t_start() call.
>>>>>>> It looks like the task does not get suspended in some cases. The
>>>>>>> return value of t_suspend() is 0 however.
>>>>>>>
>>>>>>> I suspect that this happens when the threadobj_prologue() is not
>>>>>>> finished yet at the moment that the notifier_sighandler() is called.
>>>>>>> In this case it could be that the notifier_init() did not run yet. If
>>>>>>> this is the case, then the notifier_sighandler() will not do any
>>>>>>> notifier callback and thus the task will not be suspended. Additional
>>>>>>> t_suspend() calls will not work as the "notified" flag has been set
>>>>>>> already.
>>>>>>> Is this possible?
>>>>>>>
>>>>>>
>>>>>> Unfortunately, yes.
>>>>>>
>>>>>> This is a general issue in the current implementation, as any child
>>>>>> thread
>>>>>> created by the emulation sub-system might not have fully registered
>>>>>> before
>>>>>> the parent refers to it due to priority/wait state issues.
>>>>>>
>>>>>> We definitely need stronger handshaking there, could you please
>>>>>> check again
>>>>>> with this changes in?
>>>>>> http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=a48b8f640cad510a1101e380cc54ef2bf29afcd6
>>>>>>
>>>>>>
>>>>>> TIA,
>>>>>>
>>>>>
>>>>> I tested the new revision and the problems no longer occur. So it
>>>>> looks good!
>>>>>
>>>>> Many thanks for fixing this so quickly.
>>>>>
>>>>
>>>> Hi Philippe,
>>>>
>>>> I'm afraid the new handshaking mechanism introduced to fix the
>>>> problems I was having created an actually worse problem.
>>>>
>>>> If now a parent task with high priority creates a child task with low
>>>> priority while there is another task with medium priority creating a
>>>> high load on the CPU then the parent task gets stuck in the creation
>>>> of the child. This while the parent task has a higher priority than
>>>> the task creating the load.
>>>>
>>>> I believe it is due to the fact that the parent task now waits for a
>>>> sem_post of the child, which in this case has a too low priority to
>>>> get this done.
>>>>
>>>> Should the child priority be temporary increased to the one of the
>>>> parent during the creation or would that be a bad idea?
>>>>
>>>
>>> I don't see any other option for preventing this priority inversion
>>> anyway, since the child prologue is logically part of the parent context
>>> actually. IOW, the child has to fully inherit the scheduling parameters
>>> of the parent until its prologue is over. Ok, will do this.
>>>
>>
>> Does this patch helps with your test case?
>
> Yes, this patch fixes the problem. Test case works and the original
> suspend test case also still works.
> I will run it over more tests but so far it looks good.
>

Ok, thanks. All API test suites passed here as well. So I'll push it to 
the -next branch, staging for a while. Would any issue arise with 
further testing, just pull the break.

-- 
Philippe.