[ECOS] Interrupt vs Thread - shared resource

[ECOS] Interrupt vs Thread - shared resource

[Szentirmai Gergely]

Hello

I describe my problem with a simplified example: I have a thread, which 
works with a buffer, and an ISR (or DSR), which would add some byte to 
this buffer too, so it is a shared resource. Since it is unable wait for 
a flag, or mutex in ISR, when the thread's code working with the buffer, 
the interrupt can jam the data.
The only solution is to disable the interrupt for that critical section 
in the thread? Isn't there a better solution?

I hope I was clear.

Thanks!
Gergely Szentirmai


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Interrupt vs Thread - shared resource

[Paul D. DeRocco]

> From: Szentirmai Gergely
>
> I describe my problem with a simplified example: I have a thread, which
> works with a buffer, and an ISR (or DSR), which would add some byte to
> this buffer too, so it is a shared resource. Since it is unable wait for
> a flag, or mutex in ISR, when the thread's code working with the buffer,
> the interrupt can jam the data.
> The only solution is to disable the interrupt for that critical section
> in the thread? Isn't there a better solution?

The usual method is to use a DSR, not an ISR, and then lock the scheduler in
the thread.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Interrupt vs Thread - shared resource

[Robert Brusa]

On Thu, 12 Feb 2009 02:58:03 +0100, Szentirmai Gergely  
<gergely.szentirmai@axelero.hu> wrote:

> Hello
>
> I describe my problem with a simplified example: I have a thread, which  
> works with a buffer, and an ISR (or DSR), which would add some byte to  
> this buffer too, so it is a shared resource. Since it is unable wait for  
> a flag, or mutex in ISR, when the thread's code working with the buffer,  
> the interrupt can jam the data.
> The only solution is to disable the interrupt for that critical section  
> in the thread? Isn't there a better solution?
>
> I hope I was clear.
>
> Thanks!
> Gergely Szentirmai
>
>
Well, you might block just this particular interrupt while messing around
in the DSR using cyg_drv_interrupt_mask(vector) and enable it after the
critical section using the correspoding unmask-routine. This would still  
allow other interrupts to come through.

When a "normal" task accesses critical data that are also accessed by a  
DSR use cyg_drv_dsr_lock() etc.....

Happy with this? Regards
    Robert


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Interrupt vs Thread - shared resource

[Szentirmai Gergely]

Guys, thank you for your answers!
 
Scheduler lock is an alternative to mask the interrupt, but masking the 
specific interrupt (or lock the specific DSR) is maybe better in 
performance, but too application specific (code reuse).
As I read the scheduler manual:
"However there is one situation where locking the scheduler is 
appropriate: if some data structure needs to be shared between an 
application thread and a DSR associated with some interrupt source, the 
thread can use the scheduler lock to prevent concurrent invocations of 
the DSR and then safely manipulate the structure."
It writes the same thing.
 
So there are two possible solution only; lock the scheduler, or mask the 
interrupt.
Programatically I think both solution are not "pretty" enough, because I 
have to write procedures, that bother with these "hacks" (they are not 
high level enough), rather than use a mutex, but this is an eCos 
conceptional problem (what a shame, not too user-friendly), I think...
 
Thank you for this dsr_lock idea too!
 
Gergely Szentirmai


Robert Brusa írta:
> On Thu, 12 Feb 2009 02:58:03 +0100, Szentirmai Gergely 
> <gergely.szentirmai@axelero.hu> wrote:
>
>> Hello
>>
>> I describe my problem with a simplified example: I have a thread, 
>> which works with a buffer, and an ISR (or DSR), which would add some 
>> byte to this buffer too, so it is a shared resource. Since it is 
>> unable wait for a flag, or mutex in ISR, when the thread's code 
>> working with the buffer, the interrupt can jam the data.
>> The only solution is to disable the interrupt for that critical 
>> section in the thread? Isn't there a better solution?
>>
>> I hope I was clear.
>>
>> Thanks!
>> Gergely Szentirmai
>>
>>
> Well, you might block just this particular interrupt while messing around
> in the DSR using cyg_drv_interrupt_mask(vector) and enable it after the
> critical section using the correspoding unmask-routine. This would 
> still allow other interrupts to come through.
>
> When a "normal" task accesses critical data that are also accessed by 
> a DSR use cyg_drv_dsr_lock() etc.....
>
> Happy with this? Regards
>    Robert
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Interrupt vs Thread - shared resource

[Paul D. DeRocco]

> From: Szentirmai Gergely
> 
> Guys, thank you for your answers!
>  
> Scheduler lock is an alternative to mask the interrupt, but masking the 
> specific interrupt (or lock the specific DSR) is maybe better in 
> performance, but too application specific (code reuse).
> As I read the scheduler manual:
> "However there is one situation where locking the scheduler is 
> appropriate: if some data structure needs to be shared between an 
> application thread and a DSR associated with some interrupt source, the 
> thread can use the scheduler lock to prevent concurrent invocations of 
> the DSR and then safely manipulate the structure."
> It writes the same thing.
>  
> So there are two possible solution only; lock the scheduler, or mask the 
> interrupt.
> Programatically I think both solution are not "pretty" enough, because I 
> have to write procedures, that bother with these "hacks" (they are not 
> high level enough), rather than use a mutex, but this is an eCos 
> conceptional problem (what a shame, not too user-friendly), I think...
>  
> Thank you for this dsr_lock idea too!

I wouldn't call locking the scheduler a hack--it's the normal way to interface between threads and DSRs. If you use semaphores, etc., they do the locking and unlocking for you. Indeed, the whole reason for having DSRs is that it gives you an intermediate layer which can be disabled (by locking the scheduler) without disabling interrupts.

If you have hardware that needs really fast response time, then you write an ISR which handles the really fast stuff, in which case the DSR has to do hardware-dependent interrupt masking when it accesses resources (buffer pointers, etc.) shared with the ISR.

If your hardware isn't so insanely fast, then your ISR just invokes the DSR, the DSR talks to the hardware, and the thread "masks" DSRs by locking the scheduler when it accesses resources shared with the DSR.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Interrupt vs Thread - shared resource

[Reg]

Thank your for your answer!

I understand, and agree with all the stuff that you wrote (the need of 
ISR, DSR, and the solution). The only reason why I'm calling these 
solutions "hack" (in the meaning, that not the best soulution 
(workaround) ), because the code is depending on the calling 
"enviroment", so the code is somehow application specific.
If for ex. semaphores could be used in DSRs, the code would be better, 
because the implementation of the semaphore would handle this group of 
questions (if you are in a thread, if you are in a DSR etc)
So in other words, when you write a procedure, you have to think about 
"what will call this procedure/ or use the shared resource". If only 
threads use a resource, you use mutex. If a thread and a DSR is using 
it, you have to lock scheduler or mask the interrupt or lock the 
specific DSR, just because no sinchronization object can be used in DSRs.

I think allowing the use of sinchronization objects in DSRs would be a 
great feature from eCos (would need to modify the implemetation of 
semaphore, mutex etc.)
+ better code quality
+ faster developement
+ less bugs...
- a bit more time/resource

So if DSRs are an interface or an intermediate layer between the 
"interrupt world" and the "thread world", why are we not allowed to use 
sinc. objects?

Thank you!
Gergely Szentirmai

Paul D. DeRocco írta:
>> From: Szentirmai Gergely
>>
>> Guys, thank you for your answers!
>>  
>> Scheduler lock is an alternative to mask the interrupt, but masking the 
>> specific interrupt (or lock the specific DSR) is maybe better in 
>> performance, but too application specific (code reuse).
>> As I read the scheduler manual:
>> "However there is one situation where locking the scheduler is 
>> appropriate: if some data structure needs to be shared between an 
>> application thread and a DSR associated with some interrupt source, the 
>> thread can use the scheduler lock to prevent concurrent invocations of 
>> the DSR and then safely manipulate the structure."
>> It writes the same thing.
>>  
>> So there are two possible solution only; lock the scheduler, or mask the 
>> interrupt.
>> Programatically I think both solution are not "pretty" enough, because I 
>> have to write procedures, that bother with these "hacks" (they are not 
>> high level enough), rather than use a mutex, but this is an eCos 
>> conceptional problem (what a shame, not too user-friendly), I think...
>>  
>> Thank you for this dsr_lock idea too!
>>     
>
> I wouldn't call locking the scheduler a hack--it's the normal way to interface between threads and DSRs. If you use semaphores, etc., they do the locking and unlocking for you. Indeed, the whole reason for having DSRs is that it gives you an intermediate layer which can be disabled (by locking the scheduler) without disabling interrupts.
>
> If you have hardware that needs really fast response time, then you write an ISR which handles the really fast stuff, in which case the DSR has to do hardware-dependent interrupt masking when it accesses resources (buffer pointers, etc.) shared with the ISR.
>
> If your hardware isn't so insanely fast, then your ISR just invokes the DSR, the DSR talks to the hardware, and the thread "masks" DSRs by locking the scheduler when it accesses resources shared with the DSR.
>
>   

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Interrupt vs Thread - shared resource

[Paul D. DeRocco]

> From: Reg
> 
> Thank your for your answer!
> 
> I understand, and agree with all the stuff that you wrote (the need of 
> ISR, DSR, and the solution). The only reason why I'm calling these 
> solutions "hack" (in the meaning, that not the best soulution 
> (workaround) ), because the code is depending on the calling 
> "enviroment", so the code is somehow application specific.
> If for ex. semaphores could be used in DSRs, the code would be better, 
> because the implementation of the semaphore would handle this group of 
> questions (if you are in a thread, if you are in a DSR etc)
> So in other words, when you write a procedure, you have to think about 
> "what will call this procedure/ or use the shared resource". If only 
> threads use a resource, you use mutex. If a thread and a DSR is using 
> it, you have to lock scheduler or mask the interrupt or lock the 
> specific DSR, just because no sinchronization object can be used in DSRs.
> 
> I think allowing the use of sinchronization objects in DSRs would be a 
> great feature from eCos (would need to modify the implemetation of 
> semaphore, mutex etc.)
> + better code quality
> + faster developement
> + less bugs...
> - a bit more time/resource
> 
> So if DSRs are an interface or an intermediate layer between the 
> "interrupt world" and the "thread world", why are we not allowed to use 
> sinc. objects?

Ah, I see your fundamental problem. You've misread the documentation if you think all these functions aren't usable in DSR context. Most are, as long as you don't use a function that may block. Read the bit at the end of each function description in the Reference Manual for details about the valid contexts they can be used in.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Interrupt vs Thread - shared resource

[Szentirmai Gergely]

I have read the documentation before, and the main problem is what you 
are mentioning too. You cannot call blocking instructions, such as 
|cyg_semaphore_wait, so if a thread used the shared resource when the 
scheduler started the DSR (we use semaphores) the DSR cannot wait. You 
would say we are not allowed to use blocking instructions in DSR 
context, but locking the DSR, masking the interrupt, or locking the 
scheduler has the same effect, the DSR code is blocked (not at the 
theoretical ||cyg_semaphore_wait, ||but at the "start") (or it is an 
event worth solution than allow ||cyg_semaphore_wait (rework the 
implementation of semphores)).

Thank you!
Gergely Szentirmai

|
Paul D. DeRocco írta:
>> From: Reg
>>
>> Thank your for your answer!
>>
>> I understand, and agree with all the stuff that you wrote (the need of 
>> ISR, DSR, and the solution). The only reason why I'm calling these 
>> solutions "hack" (in the meaning, that not the best soulution 
>> (workaround) ), because the code is depending on the calling 
>> "enviroment", so the code is somehow application specific.
>> If for ex. semaphores could be used in DSRs, the code would be better, 
>> because the implementation of the semaphore would handle this group of 
>> questions (if you are in a thread, if you are in a DSR etc)
>> So in other words, when you write a procedure, you have to think about 
>> "what will call this procedure/ or use the shared resource". If only 
>> threads use a resource, you use mutex. If a thread and a DSR is using 
>> it, you have to lock scheduler or mask the interrupt or lock the 
>> specific DSR, just because no sinchronization object can be used in DSRs.
>>
>> I think allowing the use of sinchronization objects in DSRs would be a 
>> great feature from eCos (would need to modify the implemetation of 
>> semaphore, mutex etc.)
>> + better code quality
>> + faster developement
>> + less bugs...
>> - a bit more time/resource
>>
>> So if DSRs are an interface or an intermediate layer between the 
>> "interrupt world" and the "thread world", why are we not allowed to use 
>> sinc. objects?
>>     
>
> Ah, I see your fundamental problem. You've misread the documentation if you think all these functions aren't usable in DSR context. Most are, as long as you don't use a function that may block. Read the bit at the end of each function description in the Reference Manual for details about the valid contexts they can be used in.
>
>   

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss