tasks blocking
Joel Sherrill
joel.sherrill at OARcorp.com
Mon Dec 3 19:50:22 UTC 2001
Ilya Alexeev wrote:
>
> Hi RTEMS users & developers.
>
> Some time ago I wrote a similar letter but I have not received any answer so
> far.
>
> I am using gen68360 bsp & rtems-ss-20011025
> and I have noticed the following problem:
>
> When creating a task with RTEMS_INTERRUPT_LEVEL which is less than the
> interrupt level of the Periodic Interrup Timer (PIT), then after calling
> the directive rtems_task_wake_after this task may not wake up, the
> probability being very high.
I can't speak to PIT problems. But I can speak to something later
which is probably confusing your interpretation.
> Here are the results of CPU_usage_Dump() after some time of testing.
>
> CPU Usage by thread
> ID NAME TICKS
> 0x04010001 IDLE 11251
> 0x08010001 INIT 4523
> 0x08010002 TSK0 513
> 0x08010003 TSK1 31
> 0x08010004 TSK2 514
> 0x08010005 TSK3 37
> 0x08010006 TSK4 18
> 0x08010007 TSK5 18
> 0x08010008 TSK6 20
> 0x08010009 TSK7 32
> 0x0801000a TSK8 6217
> 0x0801000b TSK9 512
>
> Ticks since last reset = 5823
>
> Total Units = 23480
>
> As you see, some tasks have lost their control very quickly.
When a task executes for less than 1 clock tick quantum, it is
noted as having executed 1 tick anyway. If you had a set of
tasks that did nothing but yield to one another in a tight loop,
then the "total units" would be much higher than "ticks since
last reset".
My reading of the above information is that you spend a lot of
fractional time quantums in idle with INIT and TSK8 probably
being the tasks that preempt IDLE on a regular basis.
Without a way to record microsecond resolution, this is the
best you can reliably do.
> I will be glad to receive any replies and ideas.
>
> Ilya.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list