Bug in rtems_task_set_priority()

[Kenneth Peters]

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
Ken.Peters at jpl.nasa.gov


>Hi,
>
>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
>semaphores,
>the task priority is not changed immediately or at least when the
>'resource_count' in the thread control structure is decremented back to
>zero.
>
>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
>inheritance/ceiling,
>so the second variable is not strictly necessary. If the patch is OK so
>far,
>only one counter for priority-discipline semaphores is required.
>
>I've also attached a testcase demonstrating the problem.
>
>Best regards,
>Thomas Rauscher
>
>--
>Thomas Rauscher
>LOYTEC electronics GmbH
>Stolzenthalergasse 24/3
>A-1080 Wien
>Austria/Europe
>trauscher at loytec.com
>www.loytec.com
>Phone: +43-1-4020805-15
>FAX:   +43-1-4020805-99