rtems_semaphore_obtain

[Daron Chabot]

For some reason my message didn't get through the first time. Chris, i'm
sorry if you get this twice.

When did the list become rtems.org, and not rtems.com ? Anyway...

On Tue, 2007-03-20 at 15:39 -0400, Chris Xenophontos wrote:
> 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?

see comment on this last line below.

> >
> 
> [...]
> 
> > 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.

As already covered in previous posts, [2] is not absolutely correct.

>From my understanding of cpukit/rtems/src/semcreate.c, semaphores
(mutexes) created with the priority_ceiling or priority_inherit
disciplines share the restriction that only the semaphore's "owner" may
release them.

So... since ISRs do not have an "identity", mutexes employing those
disciplines *cannot* be used from an ISR (i.e. release( )'d). However, I
haven't yet verified that this behavior is indeed what is actually
implemented.

Eric: so far, I haven't found anything that looks "racy", but that
doesn't mean there isn't :-)

-- dc