message queue vs events - VxWorks

This is a discussion on message queue vs events - VxWorks ; Hi I have task that need to process some events I hav eto choose between events or message queue does any one know when it is suitable to use events or message queue? and what is difference ? Note that ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: message queue vs events

  1. message queue vs events

    Hi

    I have task that need to process some events

    I hav eto choose between events or message queue

    does any one know when it is suitable to use events or message queue?
    and what is difference ?

    Note that no data are associated to the event

    Bye


  2. Re: message queue vs events


    mbm wrote:
    > Hi
    >
    > I have task that need to process some events
    >
    > I hav eto choose between events or message queue
    >
    > does any one know when it is suitable to use events or message queue?
    > and what is difference ?
    >
    > Note that no data are associated to the event
    >
    > Bye

    Hi,
    You would use message queues when you want to exchange bulk of data to
    other tasks and when you want one to many communication.A message queue
    is a global entity and no one owns it.So you create a message queue
    anyone can post a message to it since the queues are global data
    structures.
    When I need exchanging information between tasks,for eg,like a network
    application where I am processing the packets receieved,I would
    receieve packet in one task,post the recd packets via queue to another
    task and process it.Another eg would be data aquisation system,you
    could jus set up an interrupt when data is available and make ISR to
    post data to a message queue which could be accessed from a task and so
    I would do delayed processing as its expensive to do processing in ISR
    itself.

    OTOH,events are like signals.They are one to one communication
    systems.They are like giving an information to a task that something
    has completed where your intention is just to provide the status of
    something rather then exchanging some information between two tasks.One
    example would be like,I would have two tasks work,one which is doing
    some mpeg calculations and other task which is displaying the decoded
    image to the display.I would ask the task doing mpeg calculations to
    raise an event to display task when ever its done.Till I raise this
    event,I would do what ever I like to in the display task.You have to
    handle an event similar to how you have ISRS for hardware interrupts
    you would need a software event handler for an event.In the event
    handler you can decide what you would like to do when you recv a status
    notification.In the above eg,I would jus do some shrinking of images
    decoded to fit the size of the TV once I recv event notification from
    calculation task.
    These eg are jus tip of icebergs among plenty,jus that these come in my
    mind!

    Hope it helps,
    Regards,
    s.subbarayan


  3. Re: message queue vs events


    ssubbarayan wrote:
    > OTOH,events are like signals.They are one to one communication
    > systems.They are like giving an information to a task that something
    > has completed where your intention is just to provide the status of
    > something rather then exchanging some information between two tasks.One
    > example would be like,I would have two tasks work,one which is doing
    > some mpeg calculations and other task which is displaying the decoded
    > image to the display.I would ask the task doing mpeg calculations to
    > raise an event to display task when ever its done.Till I raise this
    > event,I would do what ever I like to in the display task.You have to
    > handle an event similar to how you have ISRS for hardware interrupts
    > you would need a software event handler for an event.In the event
    > handler you can decide what you would like to do when you recv a status
    > notification.In the above eg,I would jus do some shrinking of images
    > decoded to fit the size of the TV once I recv event notification from
    > calculation task.


    I was under impression vxWorks events (as pSos ones) are blocking and
    don't require handle. Am I totally confused?


  4. Re: message queue vs events

    Hi,
    I would not agree totally with you.As such its not mandatory to have a
    handler for an event if your intention is just to use it as status
    flag.You raise events if only you would prefer to handle them,how ever
    decision to handle and how to handle will be with the task subscribing
    to the event.
    OTOH,if you dont handle the event and just use it like a status
    indicator,I would happily go for a flag rather then an event.
    But I am confident as such vxworks does not mention anywhere that their
    events need not be handled.Can you let me know how you came to that
    conclusion?We have worked in lot of consumer appliances using vxworks
    where we handle events.
    Regards,
    s.subbarayan


  5. Re: message queue vs events


    ssubbarayan wrote:
    > Hi,
    > I would not agree totally with you.As such its not mandatory to have a
    > handler for an event if your intention is just to use it as status
    > flag.You raise events if only you would prefer to handle them,how ever
    > decision to handle and how to handle will be with the task subscribing
    > to the event.
    > OTOH,if you dont handle the event and just use it like a status
    > indicator,I would happily go for a flag rather then an event.
    > But I am confident as such vxworks does not mention anywhere that their
    > events need not be handled.Can you let me know how you came to that
    > conclusion?We have worked in lot of consumer appliances using vxworks
    > where we handle events.
    > Regards,
    > s.subbarayan


    I never used events in real life (I use vxworks 5.4) so my knowledge of
    them is rather theoretical.
    Therefore I still don't understand how you wait for an event without
    blocking the task (event != signal).


  6. Re: message queue vs events


    Vtd wrote:
    > ssubbarayan wrote:
    > > Hi,
    > > I would not agree totally with you.As such its not mandatory to have a
    > > handler for an event if your intention is just to use it as status
    > > flag.You raise events if only you would prefer to handle them,how ever
    > > decision to handle and how to handle will be with the task subscribing
    > > to the event.
    > > OTOH,if you dont handle the event and just use it like a status
    > > indicator,I would happily go for a flag rather then an event.
    > > But I am confident as such vxworks does not mention anywhere that their
    > > events need not be handled.Can you let me know how you came to that
    > > conclusion?We have worked in lot of consumer appliances using vxworks
    > > where we handle events.
    > > Regards,
    > > s.subbarayan

    >
    > I never used events in real life (I use vxworks 5.4) so my knowledge of
    > them is rather theoretical.
    > Therefore I still don't understand how you wait for an event without
    > blocking the task (event != signal).



    Hi,
    I believe its wrong to come to any conclusion until you have used the
    feature you are talking about.Then I would recommend you to gothrough
    vxworks manual 5.4 where signals are explained in detail and also if
    you need some more information on events any good RTOS book would do!
    Happy reading...
    Regards,
    s.subbarayan


  7. Re: message queue vs events


    > Hi,
    > I believe its wrong to come to any conclusion until you have used the
    > feature you are talking about.Then I would recommend you to gothrough
    > vxworks manual 5.4 where signals are explained in detail and also if
    > you need some more information on events any good RTOS book would do!
    > Happy reading...
    > Regards,
    > s.subbarayan


    You've got a weired attitude, my friend.
    I know more than enough about signals from real-time work, though I
    don't know enough about events. My original quiestion came from reading
    VxWorks 6.0 kernel programming guide p.163 which states that event
    handler is not required.
    "...Events are synchronous in nature (unlike signals), meaning that a
    receiving task must block or pend while waiting for the events to
    occur. When the desired events are received, the pending task continues
    its execution, as it would after a call to msgQReceive( ) or semTake(
    ), for example. Thus, unlike signals, events do not require a
    handler..."

    BTW from your previous posting you don't sound like vxWorks
    super-expert...


  8. Re: message queue vs events

    Hello folks,
    may I disturb your war of ...

    Vtd schrieb:
    >>Hi,


    >>I believe its wrong to come to any conclusion until you have used the
    >>feature you are talking about.

    ....
    >>vxworks manual 5.4

    ....
    >>you need some more information on events any good RTOS book would do!
    >>Happy reading...
    >>Regards,
    >>s.subbarayan

    >
    >
    > You've got a weired attitude, my friend.

    ....
    > BTW from your previous posting you don't sound like vxWorks
    > super-expert...


    I think I can understand what happened.
    There is the word "event" which is a special term in the context of
    pSOS+. Since VxWorks 5.5 it moved from pSOS+ to VxWorks kernel and so it
    arrived in VxWorks 6.x.
    The word "event" in a RTOS general meaning is not that well defined.
    So the one is talking of a resource of VxWorks 6.0, where the other did
    not know of the pSOS+ like resource.

    BTW: I am an old pSOS+ guy who tried to implement the event in VxWorks
    5.4 porting kit, so I can imagine where the confusion came from.
    So the VxWorks Version 5.5 and beyond tend to offer a migration
    path for the pSOS+ people!

    So please cool down and relax.

    Hope it helped.

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

  9. Re: message queue vs events

    Hi Martin,
    Thanks for your reply.
    I still don't understand whether vxworks event (the way it was
    introduced in 5.5 and 6.0) blocking or non-blocking sync instrument?

    Thanks again,
    Vlad


    Martin Raabe wrote:
    > Hello folks,
    > may I disturb your war of ...
    >
    > Vtd schrieb:
    > >>Hi,

    >
    > >>I believe its wrong to come to any conclusion until you have used the
    > >>feature you are talking about.

    > ...
    > >>vxworks manual 5.4

    > ...
    > >>you need some more information on events any good RTOS book would do!
    > >>Happy reading...
    > >>Regards,
    > >>s.subbarayan

    > >
    > >
    > > You've got a weired attitude, my friend.

    > ...
    > > BTW from your previous posting you don't sound like vxWorks
    > > super-expert...

    >
    > I think I can understand what happened.
    > There is the word "event" which is a special term in the context of
    > pSOS+. Since VxWorks 5.5 it moved from pSOS+ to VxWorks kernel and so it
    > arrived in VxWorks 6.x.
    > The word "event" in a RTOS general meaning is not that well defined.
    > So the one is talking of a resource of VxWorks 6.0, where the other did
    > not know of the pSOS+ like resource.
    >
    > BTW: I am an old pSOS+ guy who tried to implement the event in VxWorks
    > 5.4 porting kit, so I can imagine where the confusion came from.
    > So the VxWorks Version 5.5 and beyond tend to offer a migration
    > path for the pSOS+ people!
    >
    > So please cool down and relax.
    >
    > Hope it helped.
    >
    > --
    > BaSystem Martin Raabe
    > E: Martin.RaabeB-a-S-y-s-t-e-mde



  10. Re: message queue vs events

    Vtd wrote:
    > Hi Martin,
    > Thanks for your reply.
    > I still don't understand whether vxworks event (the way it was
    > introduced in 5.5 and 6.0) blocking or non-blocking sync instrument?
    >


    I'm also not using 5.5 or 6.0, but I can imagine the following: Each
    task control block contains some field, which is composed out of
    EventFlags. ISRs or tasks can e.g. set these EventFlags and the task can
    conditionally check if some of them are set or cleared, like usual with
    no wait, wait forever, or wait with timeout.

    Imagine a mechanism, where you are not just waiting for a semaphore, but
    for more than one thing to happen, in order for your task to unblock.

    Regards,
    Robert



    > Thanks again,
    > Vlad
    >
    >
    > Martin Raabe wrote:
    >
    >>Hello folks,
    >>may I disturb your war of ...
    >>
    >>Vtd schrieb:
    >>
    >>>>Hi,

    >>
    >>>>I believe its wrong to come to any conclusion until you have used the
    >>>>feature you are talking about.

    >>
    >>...
    >>
    >>>>vxworks manual 5.4

    >>
    >>...
    >>
    >>>>you need some more information on events any good RTOS book would do!
    >>>>Happy reading...
    >>>>Regards,
    >>>>s.subbarayan
    >>>
    >>>
    >>>You've got a weired attitude, my friend.

    >>
    >>...
    >>
    >>>BTW from your previous posting you don't sound like vxWorks
    >>>super-expert...

    >>
    >>I think I can understand what happened.
    >>There is the word "event" which is a special term in the context of
    >>pSOS+. Since VxWorks 5.5 it moved from pSOS+ to VxWorks kernel and so it
    >>arrived in VxWorks 6.x.
    >>The word "event" in a RTOS general meaning is not that well defined.
    >>So the one is talking of a resource of VxWorks 6.0, where the other did
    >>not know of the pSOS+ like resource.
    >>
    >>BTW: I am an old pSOS+ guy who tried to implement the event in VxWorks
    >> 5.4 porting kit, so I can imagine where the confusion came from.
    >> So the VxWorks Version 5.5 and beyond tend to offer a migration
    >> path for the pSOS+ people!
    >>
    >>So please cool down and relax.
    >>
    >>Hope it helped.
    >>
    >>--
    >>BaSystem Martin Raabe
    >>E: Martin.RaabeB-a-S-y-s-t-e-mde

    >
    >


+ Reply to Thread