Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. ATL / WTL / STL
  4. interthread messaging in VS/c/c++

interthread messaging in VS/c/c++

Scheduled Pinned Locked Moved ATL / WTL / STL
c++visual-studiohelpquestion
4 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Alan Kurlansky
    wrote on last edited by
    #1

    What's the lightest and easiest way to pass a message from on thread to another? The sender thread must be able to do this asynchronously so there's no to minimal time delay. The receiving thread will retrieve the thread and write it to a file. The goal here is to concentrate the hiccups associated with disk i/o to the one logging thread, so that the other working threads are not hiccup prone. It's okay that the logging thread is hiccup prone since that is all it's responsible for. Thanks for any help with this.

    L 1 Reply Last reply
    0
    • A Alan Kurlansky

      What's the lightest and easiest way to pass a message from on thread to another? The sender thread must be able to do this asynchronously so there's no to minimal time delay. The receiving thread will retrieve the thread and write it to a file. The goal here is to concentrate the hiccups associated with disk i/o to the one logging thread, so that the other working threads are not hiccup prone. It's okay that the logging thread is hiccup prone since that is all it's responsible for. Thanks for any help with this.

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #2

      Say you have a structure like so, accessible by both threads as a global variable:

      typedef struct {
      void *data;
      void *next_block;
      }block;

      The idea is to have a list of data blocks, each with a pointer to the data to be written to file, and a pointer to the next data block to be written. The sender thread will do its work, and every time data has been generated, it will allocate a new block and add its address to the next_block member of the previously last block. The next_block member of the newly added block is set to null. The receiver/writer thread will start at the beginning of the array and continuously check if next_block has been changed from a null-pointer to something else. When it's no longer null, the sender thread must have added data. This new data is written to file and may be free'd in memory. The block struct which data was written before this block's data may also be free'd now. After this, the check loop on next_block will continue, based on the last written block.

      A 1 Reply Last reply
      0
      • L Lost User

        Say you have a structure like so, accessible by both threads as a global variable:

        typedef struct {
        void *data;
        void *next_block;
        }block;

        The idea is to have a list of data blocks, each with a pointer to the data to be written to file, and a pointer to the next data block to be written. The sender thread will do its work, and every time data has been generated, it will allocate a new block and add its address to the next_block member of the previously last block. The next_block member of the newly added block is set to null. The receiver/writer thread will start at the beginning of the array and continuously check if next_block has been changed from a null-pointer to something else. When it's no longer null, the sender thread must have added data. This new data is written to file and may be free'd in memory. The block struct which data was written before this block's data may also be free'd now. After this, the check loop on next_block will continue, based on the last written block.

        A Offline
        A Offline
        Alan Kurlansky
        wrote on last edited by
        #3

        Thanks, I like this solution. Additionally I'd need to manage shared access with mutexes.

        L 1 Reply Last reply
        0
        • A Alan Kurlansky

          Thanks, I like this solution. Additionally I'd need to manage shared access with mutexes.

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          That shouldn't even be necesary in this case: If you make sure a block is initialised (data pointer valid, next_block pointer initialised) before it's appended to the list by the sender thread, it can't cause multithreading problems since the actual appending action is just one assignment.

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups