Difference between Events and Signals wrt Interprocess Communication in RTOS - Page 2

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

Translate This Thread From English to

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

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


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

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

Quoted text here. Click to load it


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.

Quoted text here. Click to load it


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


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

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Difference between Events and Signals wrt Interprocess Communication in RTOS

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



Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.


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

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!

Quoted text here. Click to load it

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


Quoted text here. Click to load it

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


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

Quoted text here. Click to load it

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!



Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

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!

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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!

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


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

Quoted text here. Click to load it

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!


Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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


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


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.

Quoted text here. Click to load it

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

Quoted text here. Click to load 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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline