Event handling in threaded C++

This is a discussion on Event handling in threaded C++ within the Linux Programming forums, part of the Platform Specific Boards category; Hi! What is the recommended way of raising an event from a threaded member function? Preferably a native solution. My ...

  1. #1
    Registered User
    Join Date
    May 2011
    Location
    Sweden
    Posts
    24

    Event handling in threaded C++

    Hi!

    What is the recommended way of raising an event from a threaded member function?
    Preferably a native solution.

    My my main.cpp, I have one class that in a threaded function continuously grabs frames from my webcam and puts them in a buffer.
    Then I have a class that handles socket stuff. Also a threaded member function

    What I want is to have the socket class to be able to "ask" the camera class for an image.

    Does that make sense?

    Any help appreciated

    //John
    Last edited by John Erlandsson; 04-17-2012 at 08:55 AM.

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,676
    Do you have any inter-thread communications now? Or are the threads currently running independently? Who is using the buffer with the frames now?

    gg

  3. #3
    Registered User
    Join Date
    May 2011
    Location
    Sweden
    Posts
    24
    Actually it is a pipeline of several image processors. They all have an in buffer and an outbuffer. The inbuffer is a pointer to another classes outbuffer. The outbuffer of the last processing class gets displayed in the main loop

    The socket class has nothing to do with the image processing classes at the moment.

  4. #4
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,338
    This seems backwards.

    If the camera is constantly producing input the filter chain should be well fed.

    Even if the filter chain isn't well fed, you kind of have to assume that the camera is doing the job you've put it to doing. With that in mind, why would the filter chain just not wait until the camera says "Hey, you, filer chain, I have another frame for you!"?

    Soma

  5. #5
    Registered User
    Join Date
    May 2011
    Location
    Sweden
    Posts
    24
    Quote Originally Posted by phantomotap View Post
    This seems backwards.

    If the camera is constantly producing input the filter chain should be well fed.

    Even if the filter chain isn't well fed, you kind of have to assume that the camera is doing the job you've put it to doing. With that in mind, why would the filter chain just not wait until the camera says "Hey, you, filer chain, I have another frame for you!"?

    Soma
    The chain works that way.

    What I need is a way for the socket thread class to tell main that it needs a fresh frame from the pipeline.

    The pipeline has a constant flow of images, but the socket class only needs a single frame when the client asks for one.

    Is the question clear enough?

    //John

  6. #6
    Registered User
    Join Date
    May 2011
    Location
    Sweden
    Posts
    24
    My only experience int this field is Qt's signal/slot.
    Something like that would be awsome, but i want to keep Qt/Boost etc out of this application. (I may want to deploy on an embedded system)

    I guess main could poll something like "bool requestingFrame()" in the socket class, but I think main has better things to do.
    Last edited by John Erlandsson; 04-18-2012 at 04:28 AM.

  7. #7
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,338
    O_o

    Yes. I did misunderstand slightly on which side of the logic the "socket" was operating.

    Now then, if you like the "Qt" system, go ahead and do it that way. It is only a variation on the "Visitor" pattern that seems to have a lot of ugliness because "Qt" is built for the wide world which unfortunately needs lots of ugly hacks.

    If `main' has something to do, you would need to spawn a new thread for `main' work and associate a bit of state with that new thread, the image chain thread, and the socket thread. These things could then communicate directly with each other by watching and signaling using relevant class methods where `main' is just chilling until everybody signals a complete state.

    *shrug*

    Because this is an embedded system, you'll have to hope you have something that supports conditional variables or events of some kind.

    That said, I'm thinking that this isn't the best approach. It means adding new state, methods, and threads to the existing design while also developing a visitor chain to handle the signals. However, if you yield the socket and filter chain threads to some other primary thread (`main') by waiting on conditions or events (signal) when they are done with a work unit you can develop a fairly simple system where the primary thread issues new commands by triggering a signal. So, for example, your `main' function would not poll a function of the socket but would wait for a "I'm done with the old frame." signal from the socket and when appropriate would issue a "You have more work to do, socket." signal.

    Soma

  8. #8
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,676
    >> What I need is a way for the socket thread class to tell main that it needs a fresh frame from the pipeline.
    From the end of the pipeline I assume. Where do frames go once they exit the pipeline now?

    Before the current frame is "thrown away" and moves on to the next one, the code could check if an external party is requesting a frame and hand it off then. Or all processed frames could go to die in a circular buffer, and 3rd parties can tap that for a recent frame.

    gg

  9. #9
    Registered User
    Join Date
    May 2011
    Location
    Sweden
    Posts
    24
    Youre both right! No need to complicate things.

    I just looked at the problem and thought signal/slot. But the "go to die in a circular buffer" approach is awsome!

    Thank you!

    //John

  10. #10
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,338
    But the "go to die in a circular buffer" approach is awsome!
    It is. Variations on the theme come up regularly with threaded code. Perhaps reach for it by default in the future instead of signals and slots.

    Soma

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. PnP event handling
    By jaypatel in forum C Programming
    Replies: 1
    Last Post: 06-24-2011, 07:00 AM
  2. threaded-safe exception handling?
    By RichSelian in forum C Programming
    Replies: 6
    Last Post: 05-13-2011, 08:35 PM
  3. Threaded time event
    By Mario F. in forum C++ Programming
    Replies: 6
    Last Post: 01-15-2007, 09:55 PM
  4. Event handling
    By gvector1 in forum C# Programming
    Replies: 4
    Last Post: 07-09-2003, 03:32 AM
  5. Event Handling
    By jaypro78 in forum C++ Programming
    Replies: 1
    Last Post: 12-15-2001, 08:55 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21