This is the mail archive of the
mailing list for the eCos project.
Re: Interrupt vs Thread - shared resource
- From: Robert Brusa <bob dot brusa at gmail dot com>
- To: "Szentirmai Gergely" <gergely dot szentirmai at axelero dot hu>, "eCos Discuss" <ecos-discuss at ecos dot sourceware dot org>
- Date: Thu, 12 Feb 2009 16:31:53 +0100
- Subject: Re: [ECOS] Interrupt vs Thread - shared resource
- References: <4993822B.firstname.lastname@example.org>
- Reply-to: Bob dot Brusa at gmail dot com
On Thu, 12 Feb 2009 02:58:03 +0100, Szentirmai Gergely
HelloWell, you might block just this particular interrupt while messing around
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.
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
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss