This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Interrupt vs Thread - shared resource
- From: Szentirmai Gergely <gergely dot szentirmai at axelero dot hu>
- To: eCos Discuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Thu, 12 Feb 2009 19:10:12 +0100
- Subject: Re: [ECOS] Interrupt vs Thread - shared resource
- References: <4993822B.7010405@axelero.hu> <op.uo8v3br7keg3uf@localhost>
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