Obtaining Semaphore in a Interrupt?

[Manuel]

Hi.

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
detail here...

Kind Regards
Manuel Coutinho

> -----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
> triggered.
> >>
> >> The problem arise when we are in a task that is in the middle of
> accessing
> >> 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
> use
> >> 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
> http://rtems.rtems.org/mailman/listinfo/rtems-users