Obtaining Semaphore in a Interrupt?
manuel.coutinho at edisoft.pt
Thu Sep 11 16:54:22 UTC 2008
That is interesting. I had never thought of that before (an ISR could not
release a semaphore with priority ceiling/inherance).
By the way, is it possible to release a semaphore with priority
ceiling/inherence inside the timer server task?
I guess it should be possible since it is a task and has a priority, so the
"new" priority will correspond to the original one when the release is
performed (in practice, nothing will happen). But perhaps I'm missing some
> -----Original Message-----
> From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org]
> On Behalf Of Joel Sherrill
> Sent: Wednesday, September 03, 2008 8:49 PM
> To: Alexandre Constantino
> Cc: rtems-users at rtems.com
> Subject: Re: Obtaining Semaphore in a Interrupt?
> Alexandre Constantino wrote:
> > Hi
> > Looking at the RTEMS user manual, inside an ISR it is not possible to
> make blocking calls, such as rtems_semaphore_obtain.
> I am glad the manual got that right. :-D
> > Hence, to ensure mutual exclusion of an area accessed both by an
> interrupt and a task you have to disable interrupts in that region.
> > A semaphore cannot protect an area accessed by an ISR (because the ISR
> cannot block).
> Right. Worse, see my comment below.
> > Best regards,
> > Alexandre Constantino
> > On Wednesday 03 September 2008, Leonard Bise wrote:
> >> Hi all,
> >> On the project I'm working on we need to protect a ressource from being
> >> accessed by multiple tasks.
> >> For this purpose we use a binary semaphore that is created in the
> >> following manner :
> >> sc = rtems_semaphore_create( rtems_build_name( 'D', 'R', 'V', 's' ), 1,
> >> RTEMS_BINARY_SEMAPHORE | RTEMS_INHERIT_PRIORITY
> >> | RTEMS_PRIORITY,
> >> RTEMS_NO_PRIORITY, &semDriver );
> Creating a binary semaphore with the above characteristics
> implies that it is being held by a thread. You want to inherit
> priority -- ISRs are not tasks and do not have priority.
> Priority inheritance and ceiling come with the idea that the
> mutex can be held by a thread which has priority and can be
> changed. It also implies that the holder will be the one releasing
> the mutex so priorities can be restored correctly.
> If you ever intend to even release a mutex/semaphore from
> an ISR, it will have to be counting or simple binary which
> do not include these semantics about priority and holder.
> >> We use a board based on a LEON2 Processor and we use a few ISR as well.
> >> These ISRs must often access the same protected ressources when
> >> The problem arise when we are in a task that is in the middle of
> >> the protected ressources and that it obtains the semaphore and that
> >> directly after an interrupt is triggered. The ISR would ask for a
> >> semaphore when the last one was not released yet, because it is in the
> >> middle of being processed. We then get a deadlock!
> >> Could anyone please help me on this ? I guess the best way is to not
> >> semaphore in ISR but how can i protect my ressource then !
> >> The version used of RTEMS is 4.6.6
> >> Regards,
> >> Bise Léonard
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
> rtems-users mailing list
> rtems-users at rtems.com
More information about the users