Difference between Events and Signals wrt Interprocess Communication in RTOS

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

ssubbarayan wrote:
> 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.

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.

Nick Maclaren wrote:
> 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.

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.

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 Raabe wrote:
> 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?

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

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

Martin Raabe wrote:
> 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,
>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

ssubbarayan wrote:
> 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.

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

By nature, yes, as they say.

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

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

Hello Lanarcam and others,

Lanarcam schrieb:
> 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