Bug in latest snapshot (patch).

[Sergei Organov]

Joel,

BTW, I've noticed that _CORE_semaphore_Seize routine (from
'c/src/exec/score/src/coresemseize.c') apparently is not used anymore. If I'm
right, it's better to remove the file, I think. If it is used, then there
could be a problem because it has different (old) implementation.

BR,
Sergei.

Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> Sergei Organov wrote:
> > 
> > I believe I've found bug in the ss-20010424 snapshot. Please see attached
> > patch.
> >
> > The bug shows itself when counting semaphore is released from ISR and obtained
> > from thread. The effect is that the thread is eventually blocked on unlocked
> > semaphore :-( I think there is a race condition in the semaphore
> > _CORE_semaphore_Seize_isr_disable code where interrupts are unlocked too early
> > (apparently due to nasty mistake introduced by copy-and-paste of code from
> > another place).
> 
> Exactly.  This is NOT (REPEAT NOT) in 4.5.0.  It was introduced by 
> an optimization to speed up semaphore and mutex operations when there
> was no contention.
> 
> This patch is necessary and there is the same bug in the macros
> version of this routine.
> 
> Chris Johns .. this could easily be the problem you saw.
> 
> > BR,
> > Sergei.
> > 
> >   ------------------------------------------------------------------------
> >                   Name: bug.diff.gz
> >    bug.diff.gz    Type: GNU Zip (application/x-gzip)
> >               Encoding: base64
> 
> -- 
> 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