Bug in rtems_task_set_priority()
Kenneth.J.Peters at jpl.nasa.gov
Fri Jan 16 00:45:05 UTC 2004
A related problem that I've run into (in 4.5.0, I don't know if it has been
dealt with already in the later versions):
If two tasks are synchronizing with a semaphore where one task always
obtains and the other always releases, the resource_count variables of the
two tasks both get continuously farther and farther from zero. Then if a
priority inheritance occurs, the priority never returns to the normal value
because resource_count never returns to zero (until it wraps :-)
This can be avoided by having the task that wants to "obtain" always do a
(release, obtain) pair, and the other task always do (obtain, release) to
keep the resource_count down. This is kludgey but doable, but it's not
obvious to the new user (or even the not-so-new user) that this needs to be
done -- especially if one side is in a timer callback which does not always
execute in the same task context, and the priority inheritance occurs
because of the "hidden" semaphores in termio when the user's code has no
priority inheritance :-(
Not clear to me if there is a better way to handle this whole issue, but I
wanted to at least get a mention of it into the mailing list archive.
Ken.Peters at jpl.nasa.gov
>we've discovered a bug in rtems_task_set_priority() in RTEMS-4.5.0.
>The problem seems to be in the mainline too, but I cannot test this.
>It occurs if a task owning a non-priority discipline semaphore
>lowers its priority or gets its priority lowered by another task.
>Its priority is not lowered then at all.
>The problem is that for a task owning only fifo and/or priority
>the task priority is not changed immediately or at least when the
>'resource_count' in the thread control structure is decremented back to
>The patch in the attachment is a first attempt to address this problem.
>Feel free to comment it.
>It creates a 'priority_resource_count' variable
>in the thread control structure which is incremented only for
>priority-discipline semaphores. All priority changing code uses the
>'priority_resource_count' instead of 'resource_count' then.
>As far as I can tell, 'resource_count' is only used for priority
>so the second variable is not strictly necessary. If the patch is OK so
>only one counter for priority-discipline semaphores is required.
>I've also attached a testcase demonstrating the problem.
>LOYTEC electronics GmbH
>trauscher at loytec.com
More information about the users