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 ; Dear all, I am not aware of the exact difference between an event and a signal.I was under impression what was available as events in other RTOS is available as Signals with Vxworks.Can you please elaborate me the difference between ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

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

  1. Difference between Events and Signals wrt Interprocess Communication in RTOS

    Dear all,

    I am not aware of the exact difference between an event and a signal.I
    was under impression what was available as events in other RTOS is
    available as Signals with Vxworks.Can you please elaborate me the
    difference between the two or point me to some links where I can get
    the difference between the two?

    Advanced thanks for your replys,
    Regards,
    s.subbarayan


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


    ssubbarayan wrote:
    > Dear all,
    >
    > I am not aware of the exact difference between an event and a signal.I
    > was under impression what was available as events in other RTOS is
    > available as Signals with Vxworks.Can you please elaborate me the
    > difference between the two or point me to some links where I can get
    > the difference between the two?
    >


    A signal is according to the unix terminology a notification sent to
    a process that will interrupt that process. In order to catch a signal
    a process must have a signal handler.

    An event is an inter task signalling mechanism that is used by some
    RTOS. You can send, receive pend for or check an event. Some RTOS
    have the concept of event flag groups where individual bits can be
    signalled.


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


    In article <1129550818.052877.298800@f14g2000cwb.googlegroups. com>,
    "Lanarcam" writes:
    |>
    |> > I am not aware of the exact difference between an event and a signal.I
    |> > was under impression what was available as events in other RTOS is
    |> > available as Signals with Vxworks.Can you please elaborate me the
    |> > difference between the two or point me to some links where I can get
    |> > the difference between the two?
    |>
    |> A signal is according to the unix terminology a notification sent to
    |> a process that will interrupt that process. In order to catch a signal
    |> a process must have a signal handler.

    I wish :-(

    The Unix signal concept is a hodge-podge. It includes all of:

    Notifications from other processes or the kernel
    Exceptions involving interrupts of the current thread
    Control operations sent to the process (SIGCONT, SIGSTOP)
    Elimination of the process without further ado (SIGKILL)
    And, heaven help us, signal zero

    |> An event is an inter task signalling mechanism that is used by some
    |> RTOS. You can send, receive pend for or check an event. Some RTOS
    |> have the concept of event flag groups where individual bits can be
    |> signalled.

    There are many other meanings of the term event, I am afraid.


    Regards,
    Nick Maclaren.

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

    Nick Maclaren wrote:
    > In article <1129550818.052877.298800@f14g2000cwb.googlegroups. com>,
    > "Lanarcam" writes:
    > |>
    > |> > I am not aware of the exact difference between an event and a signal.I
    > |> > was under impression what was available as events in other RTOS is
    > |> > available as Signals with Vxworks.Can you please elaborate me the
    > |> > difference between the two or point me to some links where I can get
    > |> > the difference between the two?
    > |>
    > |> A signal is according to the unix terminology a notification sent to
    > |> a process that will interrupt that process. In order to catch a signal
    > |> a process must have a signal handler.
    >
    > I wish :-(
    >
    > The Unix signal concept is a hodge-podge. It includes all of:
    >
    > Notifications from other processes or the kernel
    > Exceptions involving interrupts of the current thread
    > Control operations sent to the process (SIGCONT, SIGSTOP)
    > Elimination of the process without further ado (SIGKILL)
    > And, heaven help us, signal zero
    >
    > |> An event is an inter task signalling mechanism that is used by some
    > |> RTOS. You can send, receive pend for or check an event. Some RTOS
    > |> have the concept of event flag groups where individual bits can be
    > |> signalled.
    >
    > There are many other meanings of the term event, I am afraid.
    >
    >
    > Regards,
    > Nick Maclaren.

    Based on the very limited experience I've obtained from implementations
    especially in using VxWorks events, to me, in VxWorks, a
    signal("soft-interrupt") looks like a system-defined facility while a
    VxWorks event (,ported from pSos and only supported in the versions of
    5.5 and higher?) looks like a user-defined signaling facility.

    For example, to realise a VxWorks event, one needs to assoicated with
    some triggering resources such as a semaphore, or a message queue, or a
    task or an interrupt. The receiver may pend on these resources.

    A VxWorks event may be used for asynchronous inter-task communication.
    It may also be used in intra-task. An ISR can send an event but can not
    receive a one.

    Some real expert may be able to elaborate in-depth what's behind.


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

    I think a signal is just one of the several ways an event can manifest,
    and can be understood by VxWorks. May be you can say, for VxWorks the
    events are intangible but their manifestations (signal,
    interrupt..whatever) are tangible.


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

    Hello folks,

    Frank schrieb:
    > For example, to realise a VxWorks event, one needs to assoicated with
    > some triggering resources such as a semaphore, or a message queue, or a
    > task or an interrupt. The receiver may pend on these resources.



    The important difference is the common chracteristic, which is:
    signals and events are sent to a specific task. So an event is handled
    by the receiving task, so it is addressed to a specified task.

    This is not the case for message queues semaphores et. al. .

    So in pSOS+ an event is one of 32 bits in a long word in the TCB of the
    task and events can only be received by the owning task.
    So one or more events can be received at a time.

    Similar story like a signal handler, where a signal is an int, but
    received one after another.



    --
    BaSystem Martin Raabe
    E: Martin.RaabeB-a-S-y-s-t-e-mde

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


    Martin Raabe wrote:
    > Hello folks,
    >
    > Frank schrieb:
    > > For example, to realise a VxWorks event, one needs to assoicated with
    > > some triggering resources such as a semaphore, or a message queue, or a
    > > task or an interrupt. The receiver may pend on these resources.

    >

    First, I should correct myself that events are based on a synchronous
    model, NOT an asynchronous one. Are signals based on an asynchornous
    model?

    >
    > The important difference is the common chracteristic, which is:
    > signals and events are sent to a specific task. So an event is handled
    > by the receiving task, so it is addressed to a specified task.
    >
    > This is not the case for message queues semaphores et. al. .
    >
    > So in pSOS+ an event is one of 32 bits in a long word in the TCB of the
    > task and events can only be received by the owning task.
    > So one or more events can be received at a time.
    >

    So the event field (VXEVENT type) is task-specific. For inter-task
    communication, the event field is included as an argument when an event
    is sent to the receiving task. I guess the receiving task should update
    the event field of its TCB. Is this guess true?

    > Similar story like a signal handler, where a signal is an int, but
    > received one after another.
    >

    Events are accumulated, i.e., the same event received several times is
    regarded as one. I don't know if this is just the pSos/VxWorks specific
    feature. It looks like signls are not accumulated as you explained. At
    least, one can queue the signals and dispatches them to the destination
    tasks at a later time. I am afraid if one can do the same with events.


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

    Martin Raabe wrote:
    > Hello folks,
    >
    > Frank schrieb:
    > > For example, to realise a VxWorks event, one needs to assoicated with
    > > some triggering resources such as a semaphore, or a message queue, or a
    > > task or an interrupt. The receiver may pend on these resources.

    >
    >
    > The important difference is the common chracteristic, which is:
    > signals and events are sent to a specific task. So an event is handled
    > by the receiving task, so it is addressed to a specified task.
    >
    > This is not the case for message queues semaphores et. al. .
    >
    > So in pSOS+ an event is one of 32 bits in a long word in the TCB of the
    > task and events can only be received by the owning task.
    > So one or more events can be received at a time.
    >
    > Similar story like a signal handler, where a signal is an int, but
    > received one after another.
    >
    >
    >
    > --
    > BaSystem Martin Raabe
    > E: Martin.RaabeB-a-S-y-s-t-e-mde


    Martin and others,
    >From this discussion,what I have understood so far is events are

    generally like flags and a task who is sending is just setting a flag.A
    task who wishes to recieve it is going to pend checking for this flag
    and if the condition check is satisfied,its going to take necessary
    action.You can pend on more then one event using AND/OR combination.

    Where as signals are software interrupts.If this is true,is it the case
    that the recieving task is not pending for this signal?Incase the
    reciever is not pending,how will the reciever get notification that a
    signal has been raised for him?I beleive there should be some flags
    present for checking the status of signals just like hardware
    interrupts.

    Now another question comes to mind is
    Are events synchronous and signals asynchronous?
    Incase we conclude signals are asynchronous,how does the reciever task
    know when it should jump to the signal handler?

    Incase of hardware interrupts we have special registers to check status
    of interrupt.Is similar concept applicable to a signal?For eg to track
    whether a signal is in service,raised already etc?

    It would be helpful if you could clarify this.

    Regards,
    s.subbarayan


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


    ssubbarayan wrote:
    > Martin and others,
    > >From this discussion,what I have understood so far is events are

    > generally like flags and a task who is sending is just setting a flag.A
    > task who wishes to recieve it is going to pend checking for this flag
    > and if the condition check is satisfied,its going to take necessary
    > action.You can pend on more then one event using AND/OR combination.
    >
    > Where as signals are software interrupts.If this is true,is it the case
    > that the recieving task is not pending for this signal?Incase the
    > reciever is not pending,how will the reciever get notification that a
    > signal has been raised for him?I beleive there should be some flags
    > present for checking the status of signals just like hardware
    > interrupts.


    A process as they are called in unix is interrupted by the OS and
    a signal handler if it exists receives the thread of control when
    a signal is raised. The process itself does not pend for or
    check a signal. It is best to think of signals as soft interrupts.

    > Now another question comes to mind is
    > Are events synchronous and signals asynchronous?


    By nature, yes, as they say.

    > Incase we conclude signals are asynchronous,how does the reciever task
    > know when it should jump to the signal handler?


    It does not jump to the signal handler, the OS interrupts the process
    and the signal handler is executed or the process is killed if there
    is no signal handler.

    > Incase of hardware interrupts we have special registers to check status
    > of interrupt.Is similar concept applicable to a signal?For eg to track
    > whether a signal is in service,raised already etc?
    >
    > It would be helpful if you could clarify this.


    You are comparing two different systems unix and rtos which have
    characteristics of their own, this is interesting but somewhat
    artificial. In reality you are dealing with one or the other
    for a project not with both.


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

    Hello Lanarcam and others,

    Lanarcam schrieb:
    > ssubbarayan wrote:
    >>Incase of hardware interrupts we have special registers to check status
    >>of interrupt.Is similar concept applicable to a signal?For eg to track
    >>whether a signal is in service,raised already etc?


    > You are comparing two different systems unix and rtos which have
    > characteristics of their own, this is interesting but somewhat
    > artificial. In reality you are dealing with one or the other
    > for a project not with both.


    The signalhandler for signals is what the Interrupt Service Routine is
    for HW-Interrupts.

    The signal received is what the Interrupt status register is. So the
    fact that the signal handler has been called is like Interrupt pending
    implicitly. Leaving the signal handler implicitly removes the IRQ
    pending "flag". The signal handler mechanism works under the assumption,
    that for each signal the signalhandler gets called again. in pSOSystem
    you can configure, if a signal received signalhandler or not (like nested IRQs).



    --
    BaSystem Martin Raabe
    E: Martin.RaabeB-a-S-y-s-t-e-mde

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


    ssubbarayan wrote:
    > >From this discussion,what I have understood so far is events are

    > generally like flags and a task who is sending is just setting a flag.A
    > task who wishes to recieve it is going to pend checking for this flag
    > and if the condition check is satisfied,its going to take necessary
    > action.You can pend on more then one event using AND/OR combination.


    The simplest and easiest difference is, handling events is explicitly
    task's responsibilty (like waiting for event as a part of code flow
    )while handling signals is not part of code flow. As already mentioned,
    signals are software interrupts which are basically exceptional
    conditions while
    events are not. You should not use signals as interprocess
    communication primitive. When you write signal handlers, they get
    registered with the other software interrupt handlers by operating
    system. But in case of events, operating system maintains separate data
    structure like circular doubly linked list for events.

    > Where as signals are software interrupts.If this is true,is it the case
    > that the recieving task is not pending for this signal?Incase the
    > reciever is not pending,how will the reciever get notification that a
    > signal has been raised for him?I beleive there should be some flags
    > present for checking the status of signals just like hardware
    > interrupts.


    As Discussed , reiterating the point, signals are software
    interrupts.And they always run with higher priority than the task! The
    interrupt handlers identify that the signal is generated for which
    process and it will set a particulr bit in the PCB(process control
    block) for that process.This basically happens when the process is
    scheduled out to serve the ISR. While coming from the ISR, schedule
    function will be invoked and it will first look for any ready for run
    process with higher priority than the current one which was
    interrupted. If the current process is the highest priority process
    then it looks for any pending signal in the register. If it locates
    that perticular bit is set, it looks whether the signal handler is
    loaded by that task or not. If not then default signal handler will be
    invoked and action will be taken.


    > Now another question comes to mind is
    > Are events synchronous and signals asynchronous?



    Both are asynchronous but events can be made as sunchronous. Though
    signals can be , I won't suggest as it is poor programming practice
    which will reduce the performance!

    > Incase we conclude signals are asynchronous,how does the reciever task
    > know when it should jump to the signal handler?


    I answered this above!


    > Incase of hardware interrupts we have special registers to check status
    > of interrupt.Is similar concept applicable to a signal?For eg to track
    > whether a signal is in service,raised already etc?


    I answered this above!

    > It would be helpful if you could clarify this.
    >
    > Regards,
    > s.subbarayan



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

    Sagar wrote:
    > ssubbarayan wrote:
    > > > Now another question comes to mind is

    > > Are events synchronous and signals asynchronous?

    >
    >
    > Both are asynchronous but events can be made as sunchronous. Though
    > signals can be , I won't suggest as it is poor programming practice
    > which will reduce the performance!
    >

    This is from VxWorks API reference about its events:
    "Events are a means of communication between tasks and interrupt
    routines, based on a synchronous model. ..."

    I understand this by thinking that the receiving tasks are pending on
    the events. Also, events are not accumulated. If the current event is
    not handled in time, the same event coming next will overwrite the
    current one. However, unlike signals, an events may not have a default
    handler (no receiving task assigned, i.e., one can define an event
    without assigning a task to handle it).

    Can you elaborate more why events are also asynchronous? Do you think
    the synchronous model stating in the VxWorks reference manual is just
    an implementation recommendation? Does anyone have the experience
    of (or can anyone think of a case of) implementing the events in an
    asynchronous way?


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


    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!

    >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


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


    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!

    >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


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

    sorry for the same post again!!


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


    Sagar wrote:
    > ssubbarayan wrote:
    > > >From this discussion,what I have understood so far is events are

    > > generally like flags and a task who is sending is just setting a flag.A
    > > task who wishes to recieve it is going to pend checking for this flag
    > > and if the condition check is satisfied,its going to take necessary
    > > action.You can pend on more then one event using AND/OR combination.

    >
    > The simplest and easiest difference is, handling events is explicitly
    > task's responsibilty (like waiting for event as a part of code flow
    > )while handling signals is not part of code flow. As already mentioned,
    > signals are software interrupts which are basically exceptional
    > conditions while
    > events are not. You should not use signals as interprocess
    > communication primitive. When you write signal handlers, they get
    > registered with the other software interrupt handlers by operating
    > system. But in case of events, operating system maintains separate data
    > structure like circular doubly linked list for events.
    >
    > > Where as signals are software interrupts.If this is true,is it the case
    > > that the recieving task is not pending for this signal?Incase the
    > > reciever is not pending,how will the reciever get notification that a
    > > signal has been raised for him?I beleive there should be some flags
    > > present for checking the status of signals just like hardware
    > > interrupts.

    >
    > As Discussed , reiterating the point, signals are software
    > interrupts.And they always run with higher priority than the task! The
    > interrupt handlers identify that the signal is generated for which
    > process and it will set a particulr bit in the PCB(process control
    > block) for that process.This basically happens when the process is
    > scheduled out to serve the ISR. While coming from the ISR, schedule
    > function will be invoked and it will first look for any ready for run
    > process with higher priority than the current one which was
    > interrupted. If the current process is the highest priority process
    > then it looks for any pending signal in the register. If it locates
    > that perticular bit is set, it looks whether the signal handler is
    > loaded by that task or not. If not then default signal handler will be
    > invoked and action will be taken.
    >
    >
    > > Now another question comes to mind is
    > > Are events synchronous and signals asynchronous?

    >
    >
    > Both are asynchronous but events can be made as sunchronous. Though
    > signals can be , I won't suggest as it is poor programming practice
    > which will reduce the performance!


    -----------

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

    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?

    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.

    So Its not clear to me whether they are asynchronous or synchronous.
    Can some one clarify me this?

    Regards,
    s.subbarayan

    >
    > > Incase we conclude signals are asynchronous,how does the reciever task
    > > know when it should jump to the signal handler?

    >
    > I answered this above!
    >
    >
    > > Incase of hardware interrupts we have special registers to check status
    > > of interrupt.Is similar concept applicable to a signal?For eg to track
    > > whether a signal is in service,raised already etc?

    >
    > I answered this above!
    >
    > > It would be helpful if you could clarify this.
    > >
    > > Regards,
    > > s.subbarayan



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


    Sagar wrote:
    > 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?







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



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

    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.

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

    > 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


  19. Re: Difference between Events and Signals wrt Interprocess Communicationin 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.


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

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

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

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


  20. Re: 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



+ Reply to Thread
Page 1 of 2 1 2 LastLast