Difference between Events and Signals wrt Interprocess Communication in RTOS

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Dear all,

I am not aware of the exact difference between an event and a signal.I
was under impression what was available as events in other RTOS is
available as Signals with Vxworks.Can you please elaborate me the
difference between the two or point me to some links where I can get
the difference between the two?

Advanced thanks for your replys,
Regards,
s.subbarayan


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it

A signal is according to the unix terminology a notification sent to
a process that will interrupt that process. In order to catch a signal
a process must have a signal handler.

An event is an inter task signalling mechanism that is used by some
RTOS. You can send, receive pend for or check an event. Some RTOS
have the concept of event flag groups where individual bits can be
signalled.


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

|>
|> > I am not aware of the exact difference between an event and a signal.I
|> > was under impression what was available as events in other RTOS is
|> > available as Signals with Vxworks.Can you please elaborate me the
|> > difference between the two or point me to some links where I can get
|> > the difference between the two?
|>
|> A signal is according to the unix terminology a notification sent to
|> a process that will interrupt that process. In order to catch a signal
|> a process must have a signal handler.

I wish :-(

The Unix signal concept is a hodge-podge.  It includes all of:

    Notifications from other processes or the kernel
    Exceptions involving interrupts of the current thread
    Control operations sent to the process (SIGCONT, SIGSTOP)
    Elimination of the process without further ado (SIGKILL)
    And, heaven help us, signal zero

|> An event is an inter task signalling mechanism that is used by some
|> RTOS. You can send, receive pend for or check an event. Some RTOS
|> have the concept of event flag groups where individual bits can be
|> signalled.

There are many other meanings of the term event, I am afraid.


Regards,
Nick Maclaren.

Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
Quoted text here. Click to load it
Based on the very limited experience I've obtained from implementations
especially in using VxWorks events, to me, in VxWorks, a
signal("soft-interrupt") looks like a system-defined facility while a
VxWorks event (,ported from pSos and only supported in the versions of
5.5 and higher?) looks like a user-defined signaling facility.

For example, to realise a VxWorks event, one needs to assoicated with
some triggering resources such as a semaphore, or a message queue, or a
task or an interrupt. The receiver may pend on these resources.

A VxWorks event may be used for asynchronous inter-task communication.
It may also be used in intra-task. An ISR can send an event but can not
receive a one.

Some real expert may be able to elaborate in-depth what's behind.


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
I think a signal is just one of the several ways an event can manifest,
and can be understood by VxWorks. May be you can say, for VxWorks the
events are intangible but their manifestations (signal,
interrupt..whatever) are tangible.


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
Hello folks,

Frank schrieb:
Quoted text here. Click to load it


The important difference is the common chracteristic, which is:
signals and events are sent to a specific task. So an event is handled
by the receiving task, so it is addressed to a specified task.

This is not the case for message queues semaphores et. al. .

So in pSOS+ an event is one of 32 bits in a long word in the TCB of the
task and events can only be received by the owning task.
So one or more events can be received at a time.

Similar story like a signal handler, where a signal is an int, but
received one after another.



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

Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it
First, I should correct myself that events are based on a synchronous
model, NOT an asynchronous one. Are signals based on an asynchornous
model?

Quoted text here. Click to load it
So the event field (VXEVENT type) is task-specific. For inter-task
communication, the event field is included as an argument when an event
is sent to the receiving task. I guess the receiving task should update
the event field of its TCB. Is this guess true?

Quoted text here. Click to load it
Events are accumulated, i.e., the same event received several times is
regarded as one. I don't know if this is just the pSos/VxWorks specific
feature. It looks like signls are not accumulated as you explained. At
least, one can queue the signals and dispatches them to the destination
tasks at a later time. I am afraid if one can do the same with events.


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
Quoted text here. Click to load it

Martin and others,
Quoted text here. Click to load it
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.

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.

Now another question comes to mind is
Are events synchronous and signals asynchronous?
Incase we conclude signals are asynchronous,how does the reciever task
know when it should jump to the signal handler?

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?

It would be helpful if you could clarify this.

Regards,
s.subbarayan


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it

A process as they are called in unix is interrupted by the OS and
a signal handler if it exists receives the thread of control when
a signal is raised. The process itself does not pend for or
check a signal. It is best to think of signals as soft interrupts.

Quoted text here. Click to load it

By nature, yes, as they say.

Quoted text here. Click to load it

It does not jump to the signal handler, the OS interrupts the process
and the signal handler is executed or the process is killed if there
is no signal handler.

Quoted text here. Click to load it

You are comparing two different systems unix and rtos which have
characteristics of their own, this is interesting but somewhat
artificial. In reality you are dealing with one or the other
for a project not with both.


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
Hello Lanarcam and others,

Lanarcam schrieb:
Quoted text here. Click to load it


The signalhandler for signals is what the Interrupt Service Routine is
for HW-Interrupts.

The signal received is what the Interrupt status register is. So the
fact that the signal handler has been called is like Interrupt pending
implicitly. Leaving the signal handler implicitly removes the IRQ
pending "flag". The signal handler mechanism works under the assumption,
that for each signal the signalhandler gets called again. in pSOSystem
you can configure, if a signal received <can interrupt the running
signalhandler or not (like nested IRQs).



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

Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Quoted text here. Click to load it


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!

Quoted text here. Click to load it

I answered this above!


Quoted text here. Click to load it

I answered this above!

Quoted text here. Click to load it


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
Quoted text here. Click to load it
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?


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it

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!

Quoted text here. Click to load it
just an implementation recommendation?

Exaclty!!

Quoted text here. Click to load it
implementing the events in an asynchronous way?

I think I gave one example above for this!

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


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load 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?







Quoted text here. Click to load it
just an implementation recommendation?
Quoted text here. Click to load it
implementing the events in an asynchronous way?
Quoted text here. Click to load it


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
Hello Sagar,
Sagar schrieb:
Quoted text here. Click to load it
[snip]
Quoted text here. Click to load it

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

Re: Difference between Events and Signals wrt Interprocess Communicationin RTOS

Quoted text here. Click to load it

Wind River consistently used the terms "pended" and "pending" for these in
the VxWorks documentation and console displays.

Quoted text here. Click to load it

Indeed it is.

<snip>

Quoted text here. Click to load it

Can I get change back for that?  ;-)

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
We've slightly trimmed the long signature. Click to see the full one.
Re: Difference between Events and Signals wrt Interprocess Communicationin RTOS
Hello Michael,

Michael R. Kesti schrieb:
Quoted text here. Click to load it

Yes, I can offer one of the two cents.
You really have earned the money!
Please understand, that I can't afford handling and shipping, so come to
Germany and get the money by yourself.
:-)

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

Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it

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!

Quoted text here. Click to load it
just an implementation recommendation?

Exaclty!!

Quoted text here. Click to load it
implementing the events in an asynchronous way?

I think I gave one example above for this!

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


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS
sorry for the same post again!!


Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it

-----------

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

Quoted text here. Click to load it


Site Timeline