cxenophontos at hammers.com
Tue Mar 20 19:39:41 UTC 2007
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_FIFO |
I have to let it run like this another 18 hours to see if there is any
If I understand your comments, Binary Semaphores should not be called from
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
> 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, and using a mutex from ISR context
could lead to problems. I'd try to substitute counting semaphore or
event for binary semaphore and see what happens.
 I think this is a design flaw. Binary semaphore must map to the core
semaphore with counter limited by 1.
 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.
More information about the users