Re: The idea of disabling interrupts



On Nov 30, 1:11 pm, karthikbalaguru <karthikbalagur...@xxxxxxxxx>
wrote:
On Nov 29, 2:15 pm, Arlet Ottens <usene...@xxxxxxxxxx> wrote:





karthikbalaguru wrote:
If you're sharing between two tasks, it depends. Generally, if you
disable interrupts for a short period, and you don't call any OS/library
functions, it can be a useful method. Exactly how long you can disable
interrupts depends on your environment and real-time requirements.

Thx for the info. Interesting :):)

Thinking over this, i have a query -
Is it possible to do sharing of data(Critcal Section) wihtout diabling
of interrupts and also
without the use of these RTOS features like semaphore/Mutex/
MessageQueues/Pipes/Mailboxes ?

Sometimes you can use atomic instructions, if your CPU has them. For
instance, the ARM has the SWP instruction that can be used to solve some
concurrency problems.

The other possibility is to not use a preemptive RTOS. You can either
use a non-preemptive (cooperative) OS, or not use an OS at all. I've
implemented quite a few embedded systems that just had a polling loop,
and a bunch of ISRs. In some cases, the ISRs did the bulk of the work,
so there wouldn't be any concurrency issues, and the timing was guaranteed.

Thx for the info.
I thought of such a similar idea - The idea of using flags w.r.t
interrupts.
Enable a flagA and manipulate the part A
(shared data) in task code and as flagA is enabled, manipulate the
part B
in the ISR. And vice versa for part B(Shared Data).
Though this replaces the idea of disabling interrupts,
this is time consuming.

Karthik Balaguru- Hide quoted text -

- Show quoted text -

Hi,
While flags may seem to resemble in one way like a semaphore in its
way of operation,there are subtle differences and advantages on using
semaphore then a flag.
1)A flag may get modified any time and may introduce write/read
problems and that too while dealing with interrupts you always dont
know when your flag will be required.
2)If your idea is to share data between 2 tasks(strictly 2 tasks
only),flag might be useful
3)The overhead you experience with your OS structures may be high
compared to your own implementation,but I would not use my own
structures when its available from OS.Further I believe the overheads
of using these OS features are too minimal to cause a major problem
for your product or application,provided your talking about RTOS .You
can request the OS vendor for time bench marks for these operations if
you still doubt.
4)But when you are going to share data between multiple
tasks,controlling access to the flag gets a nightmare.It really needs
great thinking and effort to ensure only the right task accesses the
flag at right time.Suppose two tasks try to access data at same
time,you would not be able to decide which one to be given preference
to access the flag.This would well be solved by a semaphore.AFAIK
atleast with vxworks and OS20 you can specify during semaphore
creation the access controllability for tasks accessing the resource
using semaphores.Belive such feature would be available in most of
RTOS
5)Interrupt locks are best for short duration codes and same case
applies for taskLocks.Always as a thumb rule,locks should be for
minimal period which could be depending on your application.

Just shared my thoughts from experience,

Regards,
s.subbarayan

.



Relevant Pages

  • Re: The idea of disabling interrupts
    ... disable interrupts for a short period, and you don't call any OS/library ... While flags may seem to resemble in one way like a semaphore in its ... 1)A flag may get modified any time and may introduce write/read ... for your product or application,provided your talking about RTOS .You ...
    (comp.arch.embedded)
  • Re: Eeyore hates American movies too...
    ... these interrupts come from sources that aren't supposed to ever generate ... The set flag idea can be seen as an almost free sanity ... A WDT is like an airbag. ...
    (sci.electronics.design)
  • Re: [PATCH] Documentation: Make fujitsu/frv/kernel-ABI.txt 80 columns wide
    ... -The internal FRV kernel ABI is not quite the same as the userspace ABI. ... -most of them do not have any scratch registers, thus requiring at least one general purpose ... +single-stepping will blithely go on stepping into things like interrupts. ... -to read and once to write), we don't actually disable interrupts at all if we don't have to. ...
    (Linux-Kernel)
  • Re: Eeyore hates American movies too...
    ... these interrupts come from sources that aren't supposed to ever generate an interrupt. ... Something needs to happen upon a set flag. ... A WDT is like an airbag. ... Shouldn't go off but if it does and if the recovery after reset is handled properly it can save the situation as much as an airbag does. ...
    (sci.electronics.design)
  • Re: VMI Interface Proposal Documentation for I386, Part 4
    ... For one, the X server wants to disable interrupts temporarily during probing of dot clocks to get accurate timings, and also to avoid the kernel interrupting during a sensitive VGA register access. ... Several other userspace programs, including CMOS time sync utilities do this as well. ... The code you show above can be made to work in a virtual machine, and you can allow userspace to disable interrupts and still have a perfectly fine solution -- if you restrict the enabling and disabling of interrupts in userspace to the cli and sti instructions. ...
    (Linux-Kernel)