Difference between Events and Signals wrt Interprocess Communication in RTOS - VxWorks

This is a discussion on Difference between Events and Signals wrt Interprocess Communication in RTOS - VxWorks ; 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. > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

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

  1. Re: Difference between Events and Signals wrt InterprocessCommunicationin RTOS

    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.



    >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

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


    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


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


    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...sic.html#86380


    Cheers,
    Sagar


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


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



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


    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


  6. Re: Difference between Events and Signals wrt Interprocess Communicationin RTOS

    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


  7. Re: Difference between Events and Signals wrt Interprocess Communicationin RTOS

    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


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


    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



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2