The idea of disabling interrupts

On Nov 30, 1:11 pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> On Nov 29, 2:15 pm, Arlet Ottens <usene...@c-scape.nl> 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

On Nov 30, 2:01 pm, ssubbarayan <ssu...@gmail.com> wrote:
> On Nov 30, 1:11 pm, karthikbalaguru <karthikbalagur...@gmail.com>
> wrote:
>
>
>
>
>
> > On Nov 29, 2:15 pm, Arlet Ottens <usene...@c-scape.nl> 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.

Multually exclusive task manipulation with exclusive flags
can make a good design.

> 2)If your idea is to share data between 2 tasks(strictly 2 tasks
> only),flag might be useful

True.
With careful design , we can extend this design.
For example in assembly level programming, we handle many flags
with ease with proper correlation and care taken while implementation.
Similar scenario applies here.

> 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.

But, i think that using RTOS resouces will consume
the microprocessor resources a bit more in the
intialisation/creation stuffs. Further, making it independent of
the RTOS functions, makes efficient programming by making
it work only for the desired functionalities that we need.

> 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

Accepted.
But, creation of large number of tasks has its own drawbacks.
Context switch time will be adding to the response time.

Even large number of semaphores can cause all kind of
potential bugs . (Wrong Correlation between semaphore and task etc).

> 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.
>

True.
As long it is short it is good. But, really bad if we use it while
performing some calculations / lenghy operations as it might add
up to the response time.

Karthik Balaguru

> 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.
>

So what happens when the following sequence of events happens?

1. Task 1 reads Flag A finds that the shared data is available
2. But before it can set the flag Task 2 reads Flag A, finds shared
data available and sets the flag.
3. Task 1 runs again and sets the flag.

This is the situation that semaphores were designed to avoid. Unless
you have a processor with atomic read-modify-write a simple flag is
not going to work for two or more tasks.

TW

Ted wrote:
>> 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.
>>
> 
> So what happens when the following sequence of events happens?
> 
> 1. Task 1 reads Flag A finds that the shared data is available
> 2. But before it can set the flag Task 2 reads Flag A, finds shared
> data available and sets the flag.
> 3. Task 1 runs again and sets the flag.
> 
> This is the situation that semaphores were designed to avoid. Unless
> you have a processor with atomic read-modify-write a simple flag is
> not going to work for two or more tasks.

It can be made to work if only one task is writing the flag and the 
other one is reading it. A typical application is a ping-ping buffer 
between a task and an ISR.

In this design, there are two buffers, and a flag. The flag is written 
by the task, and read by the ISR.

If flag = 0, ISR writes to buffer A, and task reads from buffer B.
If flag = 1, ISR writes to buffer B, and task reads from buffer A.

When the task's read buffer is empty, it toggles the flag. The task 
doesn't need to disable interrupts in this case.

On Dec 3, 2:17 pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> On Nov 30, 2:01 pm, ssubbarayan <ssu...@gmail.com> wrote:
>
>
>
>
>
> > On Nov 30, 1:11 pm, karthikbalaguru <karthikbalagur...@gmail.com>
> > wrote:
>
> > > On Nov 29, 2:15 pm, Arlet Ottens <usene...@c-scape.nl> 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.
>
> Multually exclusive task manipulation with exclusive flags
> can make a good design.
>
> > 2)If your idea is to share data between 2 tasks(strictly 2 tasks
> > only),flag might be useful
>
> True.
> With careful design , we can extend this design.
> For example in assembly level programming, we handle many flags
> with ease with proper correlation and care taken while implementation.
> Similar scenario applies here.
>
> > 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.
>
> But, i think that using RTOS resouces will consume
> the microprocessor resources a bit more in the
> intialisation/creation stuffs. Further, making it independent of
> the RTOS functions, makes efficient programming by making
> it work only for the desired functionalities that we need.
>
> > 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
>
> Accepted.
> But, creation of large number of tasks has its own drawbacks.
> Context switch time will be adding to the response time.
>
> Even large number of semaphores can cause all kind of
> potential bugs . (Wrong Correlation between semaphore and task etc).
>
> > 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.
>
> True.
> As long it is short it is good. But, really bad if we use it while
> performing some calculations / lenghy operations as it might add
> up to the response time.
>
> Karthik Balaguru- Hide quoted text -
>
> - Show quoted text -

Hi,
Please see my comments embedded:
> True.
> With careful design , we can extend this design.
> For example in assembly level programming, we handle many flags
> with ease with proper correlation and care taken while implementation.
> Similar scenario applies here.

Assembly programming is quite different from what we are discussing
here.The very problem of synchronisation or mutual exclusion happens
if only theres going to be threaded or multitask environment.I believe
your assembly might not be as threaded as you see in a high level
application with an RTOS.

> But, i think that using RTOS resouces will consume
> the microprocessor resources a bit more in the
> intialisation/creation stuffs. Further, making it independent of
> the RTOS functions, makes efficient programming by making
> it work only for the desired functionalities that we need.

This is fine as far as you are careful enough.But as the code grows
its really tough to keep track of the usage.Further,generally flags if
at all used between multiple tasks should be global which may cause re
entrancy problems and if this happens I can bet its going to make it
tough to debug and fix it.This I have seen from experience.

Accepted.
> But, creation of large number of tasks has its own drawbacks.
> Context switch time will be adding to the response time.
>
> Even large number of semaphores can cause all kind of
> potential bugs . (Wrong Correlation between semaphore and task etc).

Creating large or less tasks is more application driven and design
oriented then to talk about OS.Context switch time for most RTOS under
test conditions by bench marks are in micro secs range and incase your
application needs more then this,I would say you need to choose right
OS suiting your needs.Again ,for semaphores one should be using it
only if theres no option.But using semaphores wrongly is more to do
with one's designing then the OS.If you are not careful anything is a
problem!(forget about semaphores,or flags),carelessness will be root
cause for lots of problems.
Where semaphore scores over flags are tracking mechanism is inbuilt in
a semaphore of a OS where as flags need a tracking mechanism as good
as one offered by OS.
I dont know what sort of application has constraints from resource
point which may force you to decide RTOS structures are not efficient
enough?

But these are my opinions.You are the one well aware about your needs
then any of us.

Regards,
s.subbarayan

On Dec 3, 2:45 pm, Ted <tedw...@btinternet.com> wrote:
> > 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.
>
> So what happens when the following sequence of events happens?
>
> 1. Task 1 reads Flag A finds that the shared data is available
> 2. But before it can set the flag Task 2 reads Flag A, finds shared
> data available and sets the flag.
> 3. Task 1 runs again and sets the flag.
>
> This is the situation that semaphores were designed to avoid. Unless
> you have a processor with atomic read-modify-write a simple flag is
> not going to work for two or more tasks.
>
> TW

Hi,
This is the same point I was conveying the OP.But you put it more
precise enough.

Regards,
s.subbarayan

On Dec 3, 3:24 pm, Arlet Ottens <usene...@c-scape.nl> wrote:
> Ted wrote:
> >> 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.
>
> > So what happens when the following sequence of events happens?
>
> > 1. Task 1 reads Flag A finds that the shared data is available
> > 2. But before it can set the flag Task 2 reads Flag A, finds shared
> > data available and sets the flag.
> > 3. Task 1 runs again and sets the flag.
>
> > This is the situation that semaphores were designed to avoid. Unless
> > you have a processor with atomic read-modify-write a simple flag is
> > not going to work for two or more tasks.
>
> It can be made to work if only one task is writing the flag and the
> other one is reading it. A typical application is a ping-ping buffer
> between a task and an ISR.
>
> In this design, there are two buffers, and a flag. The flag is written
> by the task, and read by the ISR.
>
> If flag = 0, ISR writes to buffer A, and task reads from buffer B.
> If flag = 1, ISR writes to buffer B, and task reads from buffer A.
>
> When the task's read buffer is empty, it toggles the flag. The task
> doesn't need to disable interrupts in this case.- Hide quoted text -
>

This is the scenario i am trying to explain.

This is the scenario i am designing for avaoiding the disabling of
interrupts. Thx for putting it with a proper example.

Thx,
Karthik Balaguru

On Dec 3, 2:45 pm, Ted <tedw...@btinternet.com> wrote:
> > 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.
>
> So what happens when the following sequence of events happens?
>
> 1. Task 1 reads Flag A finds that the shared data is available
> 2. But before it can set the flag Task 2 reads Flag A, finds shared
> data available and sets the flag.
> 3. Task 1 runs again and sets the flag.
>
> This is the situation that semaphores were designed to avoid. Unless
> you have a processor with atomic read-modify-write a simple flag is
> not going to work for two or more tasks.
>

I accept your points.
But, there is some miscommunication. (My query is not clear).
I am talking about scenarios of mutually exclusive read/write w.r.t
mutually exclusive set of flags that can avoid the disabling of
interrupts.

Thx ,
Karthik Balaguru

Arlet Ottens wrote:
> Ted wrote:
>
... snip ...
>
>> This is the situation that semaphores were designed to avoid.
>> Unless you have a processor with atomic read-modify-write a
>> simple flag is not going to work for two or more tasks.
> 
> It can be made to work if only one task is writing the flag and
> the other one is reading it. A typical application is a ping-ping
> buffer between a task and an ISR.
> 
> In this design, there are two buffers, and a flag. The flag is
> written by the task, and read by the ISR.
> 
> If flag = 0, ISR writes to buffer A, and task reads from buffer B.
> If flag = 1, ISR writes to buffer B, and task reads from buffer A.
> 
> When the task's read buffer is empty, it toggles the flag. The
> task doesn't need to disable interrupts in this case.

This requires that the process of making that decision can inhibit
the operation of the 'ISR'.  To me 'ISR' implies an interrupt
routine, so that inhibition implies disabling interrupts.  As I see
it everything can fail uncontrollably when the input rate exceeds
the output rate.  Which also implies that the interval between
input events must be large enough that the output task can empty
the current buffer.

-- 
 Chuck F (cbfalconer at maineline dot net)
   <http://cbfalconer.home.att.net>
   Try the download section.


-- 
Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:
> Arlet Ottens wrote:
>> Ted wrote:
>>
> ... snip ...
>>> This is the situation that semaphores were designed to avoid.
>>> Unless you have a processor with atomic read-modify-write a
>>> simple flag is not going to work for two or more tasks.
>> It can be made to work if only one task is writing the flag and
>> the other one is reading it. A typical application is a ping-ping
>> buffer between a task and an ISR.
>>
>> In this design, there are two buffers, and a flag. The flag is
>> written by the task, and read by the ISR.
>>
>> If flag = 0, ISR writes to buffer A, and task reads from buffer B.
>> If flag = 1, ISR writes to buffer B, and task reads from buffer A.
>>
>> When the task's read buffer is empty, it toggles the flag. The
>> task doesn't need to disable interrupts in this case.
> 
> This requires that the process of making that decision can inhibit
> the operation of the 'ISR'. 

What can go wrong if it doesn't ?

> To me 'ISR' implies an interrupt
> routine, so that inhibition implies disabling interrupts.  As I see
> it everything can fail uncontrollably when the input rate exceeds
> the output rate.  Which also implies that the interval between
> input events must be large enough that the output task can empty
> the current buffer.

Yes, ISR = interrupt service routine.

My assumption is that the buffer assigned to the ISR can store multiple 
input events. The system needs to be designed to guarantee that the task 
can empty its buffer, and switch the buffers, before the ISR fills up 
its buffer. Of course, any other kind of system needs to make similar 
guarantees.

The advantage of using ping pong buffers is that it makes it easier to 
handle a buffer full of incoming events in a burst, without having to 
worry that the buffer will be modified in the meantime.