Re: [Xenomai] FreeRTOS skin

[Philippe Gerum <rpm@xenomai.org>]

On 05/06/2014 07:19 PM, Matthias Schneider wrote:
>
> Are you referring to freertos_scheduler.sem? It is used to blocke the
> main thread while the "scheduer" is running. Even when moving the task
> cancellation loop to inside the vTaskEndScheduler(), vTaskStartScheduler()
> would still need to block until vTaskEndScheduler() is a
>

I mean you don't need a syncobj. This is overly complex for the purpose, 
you can use a sem_t. syncobj implements extended semantics we commonly 
find in RTOS, which are not available with regular POSIX ipc. But in 
this case, we don't need them: we just need to wait for a pulse, once.

>> - vTaskSuspendAll()/vTaskResumeAll() maintain useless status flags.
>> Copperplate provides __THREAD_S_SUSPENDED in the core status of threads
>> for the very same purpose.
>
> This is not entirely correct. Consider the following case (part of the demo
> actually):
>
> vTaskSuspendAll();
> vTaskSuspend(th1);
> vTaskResumeAll();
>
> This is supposed to leave th1 suspended after vTaskResumeAll(). This
> information needs to be stored somewhere. After vTaskSuspendAll(), all
> except the current thread have __THREAD_S_SUSPENDED set, so another way to
> store this informaion is needed. I have also experimented modelling these
> functions using threadobj_sched_lock() & co., however, even on UP machines
> the following code would not behave as supposed:
>
> vTaskSuspendAll();
> vTaskDelay(xGetTicksPerSecond() * 0.01);
> vTaskResumeAll();
>
> Obviously, during vTaskDelay() other tasks of lower than "sched" prio may
> be executed.

vTaskSuspendAll() very much looks like plain scheduler lock, preventing 
the caller from scheduling out on preemption. If so, then the whole 
issue disappears, there would not be any cumulative blocking states.

>
>> The other set of issues is all about locking is managed. A couple of hints:
>>
>> - vPortEnterCritical()/vPortExitCritical() can't be emulated since we
>> can't mask IRQs in userland (and we certainly don't want to even try
>> doing so). This would be a RTDM driver's business in the Xenomai model.
>> Looking at the FreeRTOS doc, the closest approximation would be
>> threadobj_sched_lock() in userland, but since hardware drivers should
>> move to kernel space over RTDM, I'm unsure emulating these calls has any
>> benefit in our context.
>
> Correct. I though I had seen use of it in the plateform-independent demo
> previously, but apparently I remember incorrectly. Defining them as empty
> functions thus.
>

I would rather not define them, to make sure the user knows about the 
issue when the compiler complains about it. Silently ignoring a hard 
critical section is unlikely to help.

-- 
Philippe.