rtems_semaphore_obtain

[Sergei Organov]

"Chris Xenophontos" <cxenophontos at hammers.com> writes:
> Hello all,
>
> We have a situation, running RTEMS 4.6.0, on a Coldfire 5208.
> One of the threads (tasks) in our application pends with a one-second
> timeout on a semaphore released by an ISR.
>
> The interrupt source that triggers the ISR (for this test case) runs every 3
> seconds (~3.011).  This re-creates the problem more frequently.
>

[...]

> status = rtems_semaphore_create( "MISR",  0, 
> ( RTEMS_FIFO | RTEMS_NO_INHERIT_PRIORITY | RTEMS_SIMPLE_BINARY_SEMAPHORE |

The binary semaphore could be a problem here. AFAIR, binary semaphore
maps to a core mutex(!) in RTEMS[1], and using a mutex from ISR context
could lead to problems[2]. I'd try to substitute counting semaphore or
event for binary semaphore and see what happens.

[1] I think this is a design flaw. Binary semaphore must map to the core
    semaphore with counter limited by 1.

[2] Mutexes are usually more restricted than semaphores. Only the thread
    that locked the mutex may unlock it, so mutexes are to be used only
    for mutual exclusion, not for synchronization. IMHO all the
    operations on mutexes (called binary semaphore in RTEMS) from ISR
    context should be explicitly prohibited.

-- 
Sergei.