| Author |
Message |
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 |
|
 |
Sagar
Guest
|
| Posted:
Fri Oct 21, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
ssubbarayan wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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!
| Quote: | 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.
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 |
|
| 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: | Frank wrote:
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!
|
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?
| Quote: |
Do you think the synchronous model stating in the VxWorks reference manual is just an implementation recommendation?
Exaclty!!
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 |
|
|
Martin Raabe
Guest
|
| Posted:
Fri Oct 21, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Hello Sagar,
Sagar schrieb:
| Quote: | The task will be in suspended state till it doesn't receive the event!!
[snip]
So the task which was waiting for the event can come from
suspended state to ready queue and take the action.(This also is
|
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 |
|
| Back to top |
|
|
Michael N. Moran
Guest
|
| Posted:
Fri Oct 21, 2005 4:13 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Sagar wrote:
| Quote: | 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.
|
It *is* from the recieving task's perspective.
| Quote: | 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.
|
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.
| Quote: | 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.
|
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.
| Quote: | 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.
--
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 |
|
| Back to top |
|
|
ssubbarayan
Guest
|
| Posted:
Fri Oct 21, 2005 4:15 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Sagar wrote:
| Quote: | 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.
| Quote: |
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?
| Quote: |
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.
| Quote: |
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 |
|
|
| Back to top |
|
|
Michael R. Kesti
Guest
|
| Posted:
Sat Oct 22, 2005 12:02 am Post subject:
Re: Difference between Events and Signals wrt Interprocess |
|
|
Martin Raabe wrote:
| Quote: | 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.
| Quote: | "Suspended" is a totally different
task state.
|
Indeed it is.
<snip>
| Quote: | 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 |
|
| Back to top |
|
|
Martin Raabe
Guest
|
| Posted:
Mon Oct 24, 2005 12:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess |
|
|
Hello Michael,
Michael R. Kesti schrieb:
| Quote: | 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 |
|
| Back to top |
|
|
Sagar
Guest
|
| Posted:
Mon Oct 24, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Michael N. Moran wrote:
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
Sagar
Guest
|
| Posted:
Mon Oct 24, 2005 8:15 am Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
ssubbarayan wrote:
| Quote: | 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!
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
ssubbarayan
Guest
|
| Posted:
Mon Oct 24, 2005 2:10 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Sagar wrote:
| Quote: | 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!
| Quote: |
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!
| Quote: |
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!
|
|
| Back to top |
|
|
Sagar
Guest
|
| Posted:
Mon Oct 24, 2005 4:06 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
ssubbarayan wrote:
| Quote: | 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!
| Quote: | 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 ....
| Quote: | 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!
| Quote: | 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 |
|
| Back to top |
|
|
Michael N. Moran
Guest
|
| Posted:
Mon Oct 24, 2005 4:14 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Sagar wrote:
| Quote: | 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 |
|
| Back to top |
|
|
Michael N. Moran
Guest
|
| Posted:
Mon Oct 24, 2005 4:15 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
ssubbarayan wrote:
| Quote: | 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.
| Quote: | 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 ;-)
| Quote: | 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 |
|
| Back to top |
|
|
ssubbarayan
Guest
|
| Posted:
Mon Oct 24, 2005 4:15 pm Post subject:
Re: Difference between Events and Signals wrt Interprocess C |
|
|
Sagar wrote:
| Quote: | 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!
| Quote: |
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?
| Quote: |
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!
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in