Mutex problem

[Joel Sherrill]

On 03/29/2011 03:39 AM, Leon Pollak wrote:
>
> I ask the community for a deep pardon - the problem found and, as 
> always, is stupid.
>
OK.  You tease us.  What was it? :D

My reading of this was that it behaved like it was supposed to.  The high
priority task "transferred" the semaphore to a low priority one and
continued to run.

--joel
>
> On Tuesday March 29 2011, Leon Pollak wrote:
>
> > Hello, all.
>
> >
>
> > I am running 4.8.0 and have some strange situation (below). Are 
> there any
>
> > known problems in this version with mutexes?
>
> > ---
>
> > Two tasks A (prio 2) and B (prio 135) are competing on a resource 
> protected
>
> > by mutex (FIFO mode). I made memory logger, which logs each suspicious
>
> > point both tasks path.
>
> > It also logs the value (I k ow the number of the semaphore to be 25):
>
> > ((Semaphore_Control*)_Semaphore_Information.local_table[25])-
>
> >
>
> > >Core_control.mutex.lock
>
> >
>
> > What I see is that A enters (lock=1), obtains the mutex (lock=0), starts
>
> > processing, waits for the I/O and at this point B enters and stands 
> waiting
>
> > for the mutex. lock=0 all the time, which seems correct.
>
> >
>
> > Then, A finishes, (lock=0), RELEASES the mutex - lock still is 0!!??
>
> > Here I supposed, that the token was implicitly passed to task B, 
> although
>
> > it does not run yet.
>
> > OK, now B continues, releases the semaphore, but lock again is 0. And
>
> > remains as such forever. The system is succefully blocked and does
>
> > nothing..:-)
>
> >
>
> > When I ask for semaphore state with the help of GDB macros, I see that
>
> > semaphore is held by task B.
>
> >
>
> > Any hint will be highly appreciated.
>
> -- 
>
> Leon
>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985