Difference between Events and Signals wrt Interprocess Communication in RTOS

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.

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?

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.

Reply to
ssubbarayan
Loading thread data ...

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

Indeed it is.

Can I get change back for that? ;-)

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
 Click to see the full signature
Reply to
Michael R. Kesti

Hello Michael,

Michael R. Kesti schrieb:

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.RaabeB-a-S-y-s-t-e-mde
Reply to
Martin Raabe

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.

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

Reply to
Sagar

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!

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

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 :

formatting link

Cheers, Sagar

Reply to
Sagar

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 agree,but whats perfect is according to the system you are dealing with!

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!

Reply to
ssubbarayan

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!

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

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!

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

formatting link

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

Reply to
Sagar

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
 Click to see the full signature
Reply to
Michael N. Moran

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.

It wasn't perfect the last time I used 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
 Click to see the full signature
Reply to
Michael N. Moran

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!

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?

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

Reply to
ssubbarayan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.