| Author |
Message |
ssubbarayan
Guest
|
 Posted:
Mon Oct 17, 2005 4:15 pm Post subject:
Difference between Events and Signals wrt Interprocess Commu |
|
|
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 |
|
| Back to top |
|
 |
Nick Maclaren
Guest
|
| Posted:
Mon Oct 17, 2005 4:15 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
In article <1129550818.052877.298800@f14g2000cwb.googlegroups.com>,
"Lanarcam" <lanarcam1@yahoo.fr> writes:
|>
|> > 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. |
|
| Back to top |
|
|
Lanarcam
Guest
|
| Posted:
Mon Oct 17, 2005 4:15 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
ssubbarayan wrote:
| Quote: | 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?
|
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. |
|
| Back to top |
|
|
Frank
Guest
|
| Posted:
Mon Oct 17, 2005 11:20 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Nick Maclaren wrote:
| Quote: | In article <1129550818.052877.298800@f14g2000cwb.googlegroups.com>,
"Lanarcam" <lanarcam1@yahoo.fr> writes:
|
|> > 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.
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. |
|
| Back to top |
|
|
Vcc Ground
Guest
|
| Posted:
Mon Oct 17, 2005 11:45 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
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. |
|
| Back to top |
|
|
Martin Raabe
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Hello folks,
Frank schrieb:
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
Frank
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Martin Raabe wrote:
| Quote: | Hello folks,
Frank schrieb:
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.
First, I should correct myself that events are based on a synchronous |
model, NOT an asynchronous one. Are signals based on an asynchornous
model?
| Quote: |
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.
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?
| Quote: | Similar story like a signal handler, where a signal is an int, but
received one after another.
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. |
|
| Back to top |
|
|
ssubbarayan
Guest
|
| Posted:
Tue Oct 18, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Martin Raabe wrote:
| Quote: | Hello folks,
Frank schrieb:
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.
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
|
Martin and others,
| Quote: | 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.
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 |
|
| Back to top |
|
|
Lanarcam
Guest
|
| Posted:
Tue Oct 18, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
ssubbarayan wrote:
| Quote: | Martin and others,
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.
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.
|
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.
| Quote: | Now another question comes to mind is
Are events synchronous and signals asynchronous?
|
By nature, yes, as they say.
| Quote: | Incase we conclude signals are asynchronous,how does the reciever task
know when it should jump to the signal handler?
|
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.
| Quote: | 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.
|
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. |
|
| Back to top |
|
|
Martin Raabe
Guest
|
| Posted:
Thu Oct 20, 2005 1:25 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Hello Lanarcam and others,
Lanarcam schrieb:
| Quote: | ssubbarayan wrote:
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?
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.
|
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 |
|
| Back to top |
|
|
Sagar
Guest
|
| Posted:
Thu Oct 20, 2005 4:15 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
ssubbarayan wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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!
| Quote: | Incase we conclude signals are asynchronous,how does the reciever task
know when it should jump to the signal handler?
|
I answered this above!
| Quote: | 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!
| Quote: | It would be helpful if you could clarify this.
Regards,
s.subbarayan |
|
|
| Back to top |
|
|
Frank
Guest
|
| Posted:
Thu Oct 20, 2005 4:15 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Sagar wrote:
| Quote: | 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? |
|
| Back to top |
|
|
ssubbarayan
Guest
|
| Posted:
Fri Oct 21, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Sagar wrote:
| Quote: | 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
| Quote: |
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 |
|
|
| Back to top |
|
|
Sagar
Guest
|
| Posted:
Fri Oct 21, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
| sorry for the same post again!! |
|
| Back to top |
|
|
Sagar
Guest
|
| Posted:
Fri Oct 21, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Frank wrote:
| Quote: | 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!
| Quote: | Do you think the synchronous model stating in the VxWorks reference manual is just an implementation recommendation?
|
Exaclty!!
| Quote: | 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 |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in