Obtaining Semaphore in a Interrupt?

Joel Sherrill joel.sherrill at OARcorp.com
Wed Sep 3 19:48:46 UTC 2008


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





More information about the users mailing list