Difference between Events and Signals wrt Interprocess Communication in RTOS

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

First of all I am talking about RTOS.I hope you are aware UNIX/LINUX
are not RTOS.Further In the case above I am referring to VXWORKS which
is a perfect RTOS.My very topic heading suggests I am talking about
RTOS.
I am sorry for not giving you information that I am talking about
Vxworks.Infact this post is cross posted to vxworks group also.
In vxworks we have a call by name Kill() which will help you to raise a
signal to other task.



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

Ok incase thats true then some one should raise the signal to the
recieving task right?Who do you think is doing the job of setting the
bit?You mean OS does itself?Definitely I beg to differ you.May be I am
not getting proper explaination I should say.Can you let me know where
you got this information?

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

That may be true with UNIX,But in vxworks thats quite not the case.I am
giving here a transcript from Vxworks programmers manual:

                 _______________>Unix equivalent call for Vxworks
                |
sigsuspend( ) pause( )--> Suspend a task until a signal is delivered.


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

Martin Raabe wrote:

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

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

>                                     "Suspended" is a totally different
>task state.

Indeed it is.

<snip>

>Just my two EURO cents.

Can I get change back for that?  ;-)

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
    mrkesti at comcast dot net     |          - The Who, Bargain

Hello Michael,

Michael R. Kesti schrieb:
> Martin Raabe wrote:
>>Just my two EURO cents.
> Can I get change back for that?  ;-)

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

Michael N. Moran wrote:
>> 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.


I am sorry for providing incomplete information in my previous post.
I didn't mention about kill.The reason behind not mentioning of kill
because in linux / unix, sending process should have real or effective
user ID equal to real or saved set-user-id of the receiving process.
Which indicates that the the processes should be from the same group
tree. And I did not want to go in the process partitioning, ownership
issues with the linux / unix. With VxWorks, it is real flat
architecture where there is no any conecept of process.I would like to
reiterate that I am not talking about VxWorks-AE. But I agree, I did a
*mistake* with not mentioning kill with the limitation of  permission!
Sorry again.

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

I agree the task is synchronising with the  asynchronous signal.
But we are getting confused here, as not happenings of the signals but
actions based on the signals are considered for behaviour. Because here
_task_ is synchronising with the signal and not the _signal_ is
synchronised! exactly like ISRs are handled when interrupts are
received! but I think every body agrees that interrupts are
asynchronous! So how come signals are considered as synchronous? 

Sagar

ssubbarayan wrote:
> First of all I am talking about RTOS.I hope you are aware UNIX/LINUX
> are not RTOS.

In my perspective, concepts are more important than the flavors
incarporating the concepts. I believe if you are aware of concepts,
your learning curve becomes very smooth. And sorry I did read only RTOS
and not VxWorks in the thread!

>Further In the case above I am referring to VXWORKS which
> is a perfect RTOS.

There is nothing perfect for embedded systems since it is not a generic
system.


> Ok incase thats true then some one should raise the signal to the
> recieving task right?Who do you think is doing the job of setting the
> bit?You mean OS does itself?Definitely I beg to differ you.May be I am
> not getting proper explaination I should say.Can you let me know where
> you got this information?

Here are the excerpts from the VxWorks manual which you are quite aware
of!

"Signals are more appropriate for error and exception handling than as
a general-purpose intertask communication mechanism. In general, signal
handlers should be treated like ISRs; no routine should be called from
a signal handler that might cause the handler to block. Because signals
are asynchronous, it is difficult to predict which resources might be
unavailable when a particular signal is raised. "
Courtesy :

http://www.eelab.usyd.edu.au/tornado/docs/vxworks/guide/c-basic.html#86380
 

Cheers,
Sagar

Sagar wrote:
> ssubbarayan wrote:
> > First of all I am talking about RTOS.I hope you are aware UNIX/LINUX
> > are not RTOS.
>
> In my perspective, concepts are more important than the flavors
> incarporating the concepts. I believe if you are aware of concepts,
> your learning curve becomes very smooth. And sorry I did read only RTOS
> and not VxWorks in the thread!

While the concepts are important then flavours,it is customised in one
way or other according to the flavour chosen,in which case it makes
sense to understand the difference with respect to the flavour you are
dealing with.Definitely even though concepts are same,there are
different OS!If all OS behave in same manner,there should be no
different OS available!



>
> >Further In the case above I am referring to VXWORKS which
> > is a perfect RTOS.
>
> There is nothing perfect for embedded systems since it is not a generic
> system.

I agree,but whats perfect is according to the system you are dealing
with!

>
>
> > Ok incase thats true then some one should raise the signal to the
> > recieving task right?Who do you think is doing the job of setting the
> > bit?You mean OS does itself?Definitely I beg to differ you.May be I am
> > not getting proper explaination I should say.Can you let me know where
> > you got this information?
>
> Here are the excerpts from the VxWorks manual which you are quite aware
> of!
>
> "Signals are more appropriate for error and exception handling than as
> a general-purpose intertask communication mechanism. In general, signal
> handlers should be treated like ISRs; no routine should be called from
> a signal handler that might cause the handler to block. Because signals
> are asynchronous, it is difficult to predict which resources might be
> unavailable when a particular signal is raised. "
> Courtesy :
>
> http://www.eelab.usyd.edu.au/tornado/docs/vxworks/guide/c-basic.html#86380
>
>

Definitely theres no contention about the asynchronous nature of
signals.The question being dealt previously by me was if the sender
does not know when to raise signal and only OS does it,it does not make
sense to provide a call by name Kill().Even though Windriver says its
used as a error and exception handling system,nothing prevents one from
using it as inter task communication mechanism.The question here is
what would happen when you use it in intertask communication and not
exactly in the aspect of its utility in other manner.Hope now you can
clear me even more better,incase you know it!
> Cheers,
> Sagar

ssubbarayan wrote:
> While the concepts are important then flavours,it is customised in one
> way or other according to the flavour chosen,in which case it makes
> sense to understand the difference with respect to the flavour you are
> dealing with.Definitely even though concepts are same,there are
> different OS!If all OS behave in same manner,there should be no
> different OS available!

I think we are going in wrong direction and this forum is not for such
kind of interactions! Lets keep it offline and we can discuss on mails
rather on the usenet!

> Definitely theres no contention about the asynchronous nature of
> signals.

Sorry my friend but you are contradicting yourself!
Look at your post on 21st Oct, 9.39 AM...
Excerpts from your post...

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

> Even though Windriver says its used as a error and exception handling
> system,nothing prevents one from  using it as inter task communication
> mechanism.

Sorry but again you are going wrong!  When the designer has designed
something, he/ she will have clear reasons behind this and will
suggesst how to use it. you should not violate these suggestions. Let
me give you example. I can write object oriented code in C, nobody
prevent me for that! but does that mean that I should use C as object
oriented language? We should always look at author's suggestions
because he / she knows what he has designed, the best and how to
exploit it in the most efficient way!

> what would happen when you use it in intertask communication and not
> exactly in the aspect of its utility in other manner.Hope now you can
> clear me even more better,incase you know it!

I think what you are looking for is the implementation of signals in
VxWorks.
And that you should _officially_ get from VxWorks technical staff
only!!
And I have already answered this query in my 20th Oct post about the
implementation of signals on linux / unix!
I did this because, linux supports POSIX standards as well as VxWorks.
And thought that it might help you in understanding from VxWorks
perspective.
Still if you are interested I will suggest you read signal chapter from
understanding linux kernel by Daniel Bovet! It helps a lot!
Even you can look at the implementation on linux on

http://lxr.linux.no

This is online source for linux. you can traverse it.
And more or less VxWorks should have the similar skeleton for signals
implementation.

cheers,
Sagar

Sagar wrote:
> I agree the task is synchronising with the  asynchronous signal.
> But we are getting confused here, as not happenings of the signals but
> actions based on the signals are considered for behaviour. Because here
> _task_ is synchronising with the signal and not the _signal_ is
> synchronised! exactly like ISRs are handled when interrupts are
> received! but I think every body agrees that interrupts are
> asynchronous! So how come signals are considered as synchronous? 

Who considers signals as synchronous? Signals are *asynchronous*.
They may be periodic or aperiodic depending upon their source,
but a signal may "interrupt" a process at any time as long as
the process' signal mask has the signal enabled, much like
the interrupt mask for a particular device.

As far as VxWorks (classic not AE) is concerned, the entire
system is essentially a single process with (potentially/usually)
multiple threads (tasks).


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

ssubbarayan wrote:
> Sagar wrote:
> 
>>ssubbarayan wrote:
>>

> Definitely even though concepts are same,there are
> different OS!If all OS behave in same manner,there should be no
> different OS available!

There *are* differences in implementation, however, the behavior
of type of signals being discussed here are essentially the same.

Yes, *nix and VxWorks are different, and are designed for
different applications. An RTOS is designed for systems where
predictable real-time response is required. Linux and *nix
systems are multi-user time-sharing systems designed to allow
many users to share computing resources.

>>>Further In the case above I am referring to VXWORKS which
>>>is a perfect RTOS.

It wasn't perfect the last time I used it ;-)

> The question here is
> what would happen when you use it in intertask communication and not
> exactly in the aspect of its utility in other manner.Hope now you can
> clear me even more better,incase you know it!

A thread calling "kill(pid_t pid, int sig)" system call
will cause the "sig" signal handler for process "pid" to
be executed when the signal is masked by the "pid" process.
Most signals will "pend" until the "pid" process unmasks
the signal, at which time the signal will be delivered.

Notice that this behavior is different from a simple
function call from the "kill()" caller to the signal
handler.

Under VxWorks, there is only one "process" and thus a
signal can be stimulated only by the same "process"
(not necessarily the same thread/task) or potentially
by an interrupt handler.

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

Sagar wrote:
> ssubbarayan wrote:
> > While the concepts are important then flavours,it is customised in one
> > way or other according to the flavour chosen,in which case it makes
> > sense to understand the difference with respect to the flavour you are
> > dealing with.Definitely even though concepts are same,there are
> > different OS!If all OS behave in same manner,there should be no
> > different OS available!
>
> I think we are going in wrong direction and this forum is not for such
> kind of interactions! Lets keep it offline and we can discuss on mails
> rather on the usenet!
>
> > Definitely theres no contention about the asynchronous nature of
> > signals.
>
> Sorry my friend but you are contradicting yourself!
> Look at your post on 21st Oct, 9.39 AM...
> Excerpts from your post...
>
> 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 ....

If you would have looked into my other posts as the discussions went on
I have said that from my understanding reading from posts,Informed that
signals can be asynchronous where as events may not necessarily be so.I
wont say its contradicting myself,rather its the clarity I got after
discussing with all helpful people here including you!


>
> > Even though Windriver says its used as a error and exception handling
> > system,nothing prevents one from  using it as inter task communication
> > mechanism.
>
> Sorry but again you are going wrong!  When the designer has designed
> something, he/ she will have clear reasons behind this and will
> suggesst how to use it. you should not violate these suggestions. Let
> me give you example. I can write object oriented code in C, nobody
> prevent me for that! but does that mean that I should use C as object
> oriented language? We should always look at author's suggestions
> because he / she knows what he has designed, the best and how to
> exploit it in the most efficient way!

There should be reason behind why its not prefered.I am just trying to
understand the reason behind it.By the way please dont take me in wrong
sense,my postings are to enter into clear understanding and not to
enter into any thing which may not be in its context!
Definitely author should have said it with reason,are you aware of it?

>
> > what would happen when you use it in intertask communication and not
> > exactly in the aspect of its utility in other manner.Hope now you can
> > clear me even more better,incase you know it!
>
> I think what you are looking for is the implementation of signals in
> VxWorks.
> And that you should _officially_ get from VxWorks technical staff
> only!!
> And I have already answered this query in my 20th Oct post about the
> implementation of signals on linux / unix!
> I did this because, linux supports POSIX standards as well as VxWorks.
> And thought that it might help you in understanding from VxWorks
> perspective.
> Still if you are interested I will suggest you read signal chapter from
> understanding linux kernel by Daniel Bovet! It helps a lot!
> Even you can look at the implementation on linux on
>
> http://lxr.linux.no
>
> This is online source for linux. you can traverse it.
> And more or less VxWorks should have the similar skeleton for signals
> implementation.

Thanks for this suggestion,will definitely have a look at it!


> 
> cheers,
> Sagar