Bug in rtems_task_set_priority()

[Kenneth Peters]

It looks like the main line of code leading to 4.6 has a fix (since 2001, 
actually) similar to what Thomas has suggested. All the semaphore/mutex 
routines were streamlined at the same time, so it's hard to tell by 
inspection whether the problem I was having is fixed, but it looks like 
using non-priority-inheriting binary semaphores would do what I want.

I think the philosophical point is that in 4.5.0, all binary semaphores 
(inheriting and non-inheriting) really need to be treated as tokens, where 
a task that takes them must release them, or inheritance can get confused. 
In 4.5.1+, it looks like non-inheriting binary semaphores can be used for 
task synchronization where obtains and releases are not paired in each 
task, but I'm not sure whether inheriting binary semaphores must still be 
treated as tokens.

For my needs, I will probably use 4.5.0 counting semaphores. I lose the 
ability to use priority inheritance on them, but since I am not using them 
as mutexes, I can get away with that. I might make myself a function to set 
the semaphore maximum_value to be one, so they will act as binary 
semaphores in that respect. Once 4.6 is officially released, all troubles 
will be things of the past :-)

Ken Peters
Ken.Peters at jpl,nasa.gov

At 02:38 PM 1/16/2004 +0100, Thomas Rauscher wrote:
> > -----Original Message-----
> > From: Kenneth Peters [mailto:Kenneth.J.Peters at jpl.nasa.gov]
> > Sent: Friday, January 16, 2004 1:45 AM
> > To: RTEMS Users
> > Subject: Re: Bug in rtems_task_set_priority()
> >
> > 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
> >
>
>I've submitted an RTEMS bug report (PR551) at least for my problem.
>Maybe these two are closely related, so it's worth looking at them both.
>
>Maybe you can try the patch I've sent in one of my former mails.
>It limits the effects of the resource_count variable to
>priority discipline mutexes. However, I'm not sure that it breaks other
>code but until now I do not experience any other problems.
>
>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