Difference between Events and Signals wrt Interprocess Communication in RTOS

ssubbarayan wrote:
> >From this discussion,what I have understood so far is events are
> generally like flags and a task who is sending is just setting a flag.A
> task who wishes to recieve it is going to pend checking for this flag
> and if the condition check is satisfied,its going to take necessary
> action.You can pend on more then one event using AND/OR combination.

The simplest and easiest difference is, handling events is explicitly
task's responsibilty (like waiting for event as a part of code flow
)while handling signals is not part of code flow. As already mentioned,
signals are software interrupts which are basically exceptional
conditions while
events are not. You should not use signals as interprocess
communication primitive. When you write signal handlers, they get
registered with the other software interrupt handlers by operating
system. But in case of events, operating system maintains separate data
structure like circular doubly linked list for events.

> Where as signals are software interrupts.If this is true,is it the case
> that the recieving task is not pending for this signal?Incase the
> reciever is not pending,how will the reciever get notification that a
> signal has been raised for him?I beleive there should be some flags
> present for checking the status of signals just like hardware
> interrupts.

As Discussed , reiterating the point, signals are software
interrupts.And they always run with higher priority than the task! The
interrupt handlers identify that the signal is generated for which
process and it will set a particulr bit in the PCB(process control
block) for that process.This basically happens when the process is
scheduled out to serve the ISR. While coming from the ISR, schedule
function will be invoked and it will first look for any ready for run
process with higher priority than the current one which was
interrupted. If the current process is the highest priority process
then it looks for any pending signal in the register. If it locates
that perticular bit is set, it looks whether the signal handler is
loaded by that task or not. If not then default signal handler will be
invoked and action will be taken.


> Now another question comes to mind is
> Are events synchronous and signals asynchronous?


Both are asynchronous but events can be made as sunchronous. Though
signals can be , I won't suggest as it is poor programming practice
which will reduce the performance!

> Incase we conclude signals are asynchronous,how does the reciever task
> know when it should jump to the signal handler?

I answered this above!


> Incase of hardware interrupts we have special registers to check status
> of interrupt.Is similar concept applicable to a signal?For eg to track
> whether a signal is in service,raised already etc?

I answered this above!

> It would be helpful if you could clarify this.
> 
> Regards,
> s.subbarayan

Sagar wrote:
> ssubbarayan wrote:
> > > Now another question comes to mind is
> > Are events synchronous and signals asynchronous?
>
>
> Both are asynchronous but events can be made as sunchronous. Though
> signals can be , I won't suggest as it is poor programming practice
> which will reduce the performance!
>
This is from VxWorks API reference about its events:
"Events are a means of communication between tasks and interrupt
routines, based on a synchronous model. ..."

I understand this by thinking that the receiving tasks are pending on
the events. Also, events are not accumulated. If the current event is
not handled in time, the same event coming next will overwrite the
current one. However, unlike signals, an events may not have a default
handler (no receiving task assigned, i.e., one can define an event
without assigning a task to handle it).

Can you elaborate more why events are also asynchronous? Do you think
the synchronous model stating in the VxWorks reference manual is just
an implementation recommendation? Does anyone have the experience
of (or can anyone think of a case of) implementing the events in an
asynchronous way?

Frank wrote:
> Can you elaborate more why events are also asynchronous?

I think, I said they can be used as synchronous way of communication.
It is important how you use it!! Let me elaborate this. Consider a
thread taking an action based on the event. It doesn't bother who fires
this event. What is important is that it is waiting in a loop for the
event.
Now assume that this event is being fired when data is receieved from
I/O device! And the ISR handling this device will fire the event to
indicate that the data is in the buffer. What will you call this?
Asynchronous or synchronous? (though generally this way of design is
not considered as pertinent design!)The task will be in suspended state
till it doesn't receive the event!! Which the device only knows for how
much time it will in suspended state!!
         What VxWorks manual enforces that events should be used as
inter process communication like to intimate the another task that it
has done something interesting for it and it is free to take the
action. So the task which was waiting for the event can come from
suspended state to ready queue and take the action.(This also is
basically done by the scheduler. In case of rate monotonic scheduler,
the implementation is different!) This is generally done as a periodic
action! Means one thread will generate the event and other thread will
take some action based on that event. Now if I design my thead to fire
the event in aperiodic manner, do you call it as synchronous? So that's
why I said, it is basically how you use it!

>Do you think the synchronous model stating in the VxWorks reference manual is just an implementation recommendation?

Exaclty!!

>Does anyone have the experience of (or can anyone think of a case of) implementing the events in an asynchronous way?

I think I gave one example above for this!

-----------
Sagar

Frank wrote:
> Can you elaborate more why events are also asynchronous?

I think, I said they can be used as synchronous way of communication.
It is important how you use it!! Let me elaborate this. Consider a
thread taking an action based on the event. It doesn't bother who fires
this event. What is important is that it is waiting in a loop for the
event.
Now assume that this event is being fired when data is receieved from
I/O device! And the ISR handling this device will fire the event to
indicate that the data is in the buffer. What will you call this?
Asynchronous or synchronous? (though generally this way of design is
not considered as pertinent design!)The task will be in suspended state
till it doesn't receive the event!! Which the device only knows for how
much time it will in suspended state!!
         What VxWorks manual enforces that events should be used as
inter process communication like to intimate the another task that it
has done something interesting for it and it is free to take the
action. So the task which was waiting for the event can come from
suspended state to ready queue and take the action.(This also is
basically done by the scheduler. In case of rate monotonic scheduler,
the implementation is different!) This is generally done as a periodic
action! Means one thread will generate the event and other thread will
take some action based on that event. Now if I design my thead to fire
the event in aperiodic manner, do you call it as synchronous? So that's
why I said, it is basically how you use it!

>Do you think the synchronous model stating in the VxWorks reference manual is just an implementation recommendation?

Exaclty!!

>Does anyone have the experience of (or can anyone think of a case of) implementing the events in an asynchronous way?

I think I gave one example above for this!

-----------
Sagar

sorry for the same post again!!

Sagar wrote:
> ssubbarayan wrote:
> > >From this discussion,what I have understood so far is events are
> > generally like flags and a task who is sending is just setting a flag.A
> > task who wishes to recieve it is going to pend checking for this flag
> > and if the condition check is satisfied,its going to take necessary
> > action.You can pend on more then one event using AND/OR combination.
>
> The simplest and easiest difference is, handling events is explicitly
> task's responsibilty (like waiting for event as a part of code flow
> )while handling signals is not part of code flow. As already mentioned,
> signals are software interrupts which are basically exceptional
> conditions while
> events are not. You should not use signals as interprocess
> communication primitive. When you write signal handlers, they get
> registered with the other software interrupt handlers by operating
> system. But in case of events, operating system maintains separate data
> structure like circular doubly linked list for events.
>
> > Where as signals are software interrupts.If this is true,is it the case
> > that the recieving task is not pending for this signal?Incase the
> > reciever is not pending,how will the reciever get notification that a
> > signal has been raised for him?I beleive there should be some flags
> > present for checking the status of signals just like hardware
> > interrupts.
>
> As Discussed , reiterating the point, signals are software
> interrupts.And they always run with higher priority than the task! The
> interrupt handlers identify that the signal is generated for which
> process and it will set a particulr bit in the PCB(process control
> block) for that process.This basically happens when the process is
> scheduled out to serve the ISR. While coming from the ISR, schedule
> function will be invoked and it will first look for any ready for run
> process with higher priority than the current one which was
> interrupted. If the current process is the highest priority process
> then it looks for any pending signal in the register. If it locates
> that perticular bit is set, it looks whether the signal handler is
> loaded by that task or not. If not then default signal handler will be
> invoked and action will be taken.
>
>
> > Now another question comes to mind is
> > Are events synchronous and signals asynchronous?
>
>
> Both are asynchronous but events can be made as sunchronous. Though
> signals can be , I won't suggest as it is poor programming practice
> which will reduce the performance!

-----------

Sagar and others,
How can you say that signals are asynchronous?I can see that from a
sending tasks perspective you can raise a signal to any reciever
task.That means you know very well when you are going to send it and
and when the reciever is going to recieve it.Only way I can see it is
as asynchronous is from the recieving tasks perspective that ,it will
jump to signal handler rather then the tasks code.So If you know
already where its going to be sent and since you are not bothered about
the status of the recieving task when you are sending the signal,I
believe you are saying it as asynchronous from a recieving tasks
context.

Incase ,what I said above is true,then the recievers task is not going
to pend for it.So OS needs to keep on checking this particulr bit in
the tasks context every time a context switch happens.Are you sure this
happens?

Further I am seeing a call sigsuspend() which provides the facility of
a task to go in for suspension till a signal is raised to it.This I see
can be used to mimic the synchronous behaviour.

So Its not clear to me whether they are asynchronous or synchronous.
Can some one clarify me this?

Regards,
s.subbarayan

>
> > Incase we conclude signals are asynchronous,how does the reciever task
> > know when it should jump to the signal handler?
>
> I answered this above!
>
>
> > Incase of hardware interrupts we have special registers to check status
> > of interrupt.Is similar concept applicable to a signal?For eg to track
> > whether a signal is in service,raised already etc?
>
> I answered this above!
>
> > It would be helpful if you could clarify this.
> > 
> > Regards,
> > s.subbarayan

Sagar wrote:
> Frank wrote:
> > Can you elaborate more why events are also asynchronous?
>
> I think, I said they can be used as synchronous way of communication.
> It is important how you use it!! Let me elaborate this. Consider a
> thread taking an action based on the event. It doesn't bother who fires
> this event. What is important is that it is waiting in a loop for the
> event.
> Now assume that this event is being fired when data is receieved from
> I/O device! And the ISR handling this device will fire the event to
> indicate that the data is in the buffer. What will you call this?
> Asynchronous or synchronous? (though generally this way of design is
> not considered as pertinent design!)The task will be in suspended state
> till it doesn't receive the event!! Which the device only knows for how
> much time it will in suspended state!!
>          What VxWorks manual enforces that events should be used as
> inter process communication like to intimate the another task that it
> has done something interesting for it and it is free to take the
> action. So the task which was waiting for the event can come from
> suspended state to ready queue and take the action.(This also is
> basically done by the scheduler. In case of rate monotonic scheduler,
> the implementation is different!) This is generally done as a periodic
> action! Means one thread will generate the event and other thread will
> take some action based on that event. Now if I design my thead to fire
> the event in aperiodic manner, do you call it as synchronous? So that's
> why I said, it is basically how you use it!

I would like to say,the recieving task in this case need not
necessarily be suspended,it can be pended!
I will do something like this:
Sender task
{
........
Raise event( event e1);
}

Reciever task
{

if (e1)

{
.....
}
else
{
....
}

(OR EVEN CHANGE IT LIKE THIS:
MAKE THE SENDER TASK PROVIDE A SEMAPHORE WHEN HE SENDS A EVENT AND MAKE
RECIEVER TASK PEND FOR HIM,AND WHEN HE RECIEVES IT,HE KNOWS EVENT HAS
HAPPENED AND TAKE NECESSARY ACTION.WHILE WHAT I SAID MAY DEFEAT THE
VERY PURPOSE
OF EVENT,THIS CAN BE PROVING THAT EVENTS ARE SYNCHRONOUS!)

}

This is just a pseudo code and does not reflect real API.
If you can see I can check at anypoint of time  and take action in the
recieving task.Where as in case of signals you cannot check something
like this until you are able to gain access to the particular bit
stated by you which is present in the tasks context block.I dont know
and not sure whether such a thing is possible.
And also,even though the firing of event is asynchronous in the sense
you dont know when it will fire,the reciever is well aware when to
check for it.Where as in case of signals,you cant check it (according
to your own words!).
This verywell contradicts the fact that events are asynchronous!
Can you substantiate further on your statement?







>
> >Do you think the synchronous model stating in the VxWorks reference manual is just an implementation recommendation?
>
> Exaclty!!
>
> >Does anyone have the experience of (or can anyone think of a case of) implementing the events in an asynchronous way?
> 
> I think I gave one example above for this!
> 
> -----------
> Sagar

ssubbarayan wrote:
> Sagar and others,
> How can you say that signals are asynchronous?I can see that from a
> sending tasks perspective you can raise a signal to any reciever
> task.

I would like to explain the meaning from dictionary for the terms:

Synchronous: Occurring or existing at the same time or having the same
period or phase

Asynchronous: Not Synchronous

When we define something, it should not be inclined to a particular
thing but to the most general way so that it can be considered as a
standard!
So we should not define the words from task's perspective.

> That means you know very well when you are going to send it and
> and when the reciever is going to recieve it.Only way I can see it is
> as asynchronous is from the recieving tasks perspective that ,it will
> jump to signal handler rather then the tasks code. So If you know
> already where its going to be sent and since you are not bothered about
> the status of the recieving task when you are sending the signal,I
> believe you are saying it as asynchronous from a recieving tasks
> context.

First of all you can't raise signals to other processes as per my
knowledge of Linux / Unix!! Any user process is not allowed to raise
the signals for other process. Refer to raise man page! So I don't know
which case you are talking about.Only kernel can raise the signals to
the user processes!Either you can raise it through your part of code as
exception handling or kernel can raise it when we do some obnoxious
activity in the code.
If you elaborate this with practical example of raising signals for
other processes, I will think about it.

> Incase ,what I said above is true,then the recievers task is not going
> to pend for it.So OS needs to keep on checking this particulr bit in
> the tasks context every time a context switch happens.Are you sure this
> happens?

100 % sure!! Operating system will always first check for the signals
pending in the register before giving control to the application!

> Further I am seeing a call sigsuspend() which provides the facility of
> a task to go in for suspension till a signal is raised to it.This I see
> can be used to mimic the synchronous behaviour.

sigsuspend() description is

The sigsuspend() function shall replace the current signal mask of the
calling thread with the set of signals pointed to by sigmask and then
suspend the thread until delivery of a signal whose action is either to
execute a signal-catching function or to terminate the process. This
shall not cause any other signals that may have been pending on the
process to become pending on the thread.

If the action is to terminate the process then sigsuspend() shall never
return. If the action is to execute a signal-catching function, then
sigsuspend() shall return after the signal-catching function returns,
with the signal mask restored to the set that existed prior to the
sigsuspend() call.

It is not possible to block signals that cannot be ignored. This is
enforced by the system without causing an error to be indicated.
------

I don't know how this makes you to think like synchronous way of
signals!
Rather it proves that the time for receiving the signal is unknown
which is asynchronous!

Cheers,

Sagar

Hello Sagar,
Sagar schrieb:
> The task will be in suspended state till it doesn't receive the event!! 
[snip]
> So the task which was waiting for the event can come from
> suspended state to ready queue and take the action.(This also is

Please do me a favor and don't call the task's state "suspended".
the task is "blocked" or "blocking". "Suspended" is a totally different 
task state.

Usually regarding task states events and other inter process
communication resources are used to bring tasks in "blocked" state, when 
they are waiting. This is seen as "synchronous".
When a task is in the "ready" or "running" task state and gets 
"suspended", which is out of the tasks control by the way, this is seen 
as "asynchronous". The same is true for the signal handling, which is 
using a task state very close to being suspended temporarly. The task 
state switch to "executing signal handler" also is (mostly) out of the 
control of the task it self.

Just my two EURO cents.

-- 
BaSystem Martin Raabe
E: Martin.Raabe<at>B-a-S-y-s-t-e-m<dot>de

Sagar wrote:
> ssubbarayan wrote:
> 
>>Sagar and others,
>>How can you say that signals are asynchronous?I can see that from a
>>sending tasks perspective you can raise a signal to any reciever
>>task.

It *is* from the recieving task's perspective.

> Synchronous: Occurring or existing at the same time or having the same
> period or phase
> 
> Asynchronous: Not Synchronous
> 
> When we define something, it should not be inclined to a particular
> thing but to the most general way so that it can be considered as a
> standard!
> So we should not define the words from task's perspective.

This is *not* true. Signals are analogous to interrupts. The source
of an interrupt may or may not be synchronized with the CPU receiving
the interrupt, but from the CPU's point-of-view, the interrupt may
happen at any time and therefore is asynchronous.

> First of all you can't raise signals to other processes as per my
> knowledge of Linux / Unix!! Any user process is not allowed to raise
> the signals for other process.

This is simply wrong. Signals may come from other processes.
(e.g. the *nix kill command.) Whether or not the sending process
has *permission* to send the signal to another process is another
issue.

>>Further I am seeing a call sigsuspend() which provides the facility of
>>a task to go in for suspension till a signal is raised to it.This I see
>>can be used to mimic the synchronous behaviour.

sigsuspend() allows the "task" to block until a signal is received
if the task has nothing better to do. In this case the task is
synchronizing with the asynchronous signal. Analogous to a CPU
going into a low power sleep state until an external
(asynchronous) interrupt wakes the CPU.



-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1