rtems_semaphore_obtain

[Chris Xenophontos]

The first change I've made is to create a Counting Semaphore, i.e, changed
the attributes of the semaphore in question from:

( RTEMS_FIFO | 
  RTEMS_NO_INHERIT_PRIORITY | 
  RTEMS_SIMPLE_BINARY_SEMAPHORE | 
  RTEMS_NO_PRIORITY_CEILING | 
  RTEMS_LOCAL ), 

to:

( RTEMS_FIFO | 
  RTEMS_NO_INHERIT_PRIORITY | 
  RTEMS_COUNTING_SEMAPHORE  |
  RTEMS_NO_PRIORITY_CEILING | 
  RTEMS_LOCAL ),

I have to let it run like this another 18 hours to see if there is any
change.  

If I understand your comments, Binary Semaphores should not be called from
ISRs? 

thanks
Chris Xenophontos


-----Original Message-----
From: Sergei Organov [mailto:osv at javad.com] 
Sent: Tuesday, March 20, 2007 1:40 PM
To: Chris Xenophontos
Cc: rtems-users at rtems.org; 'Tom Phillips'
Subject: Re: rtems_semaphore_obtain

"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.