在c ++中，在线程之间共享数据容器的最佳方法是什么

Question

I have an application which has a couple of processing levels like:

InputStream->Pre-Processing->Computation->OutputStream

Each of these entities run in separate thread. So in my code I have the general thread, which owns the

std::vector<ImageRead> m_readImages;

and then it passes this member variable to each thread:

InputStream input{&m_readImages};
std::thread threadStream{&InputStream::start, &InputStream};
PreProcess pre{&m_readImages};
std::thread preStream{&PreProcess::start, &PreProcess};
...

And each of these classes owns a pointer member to this data:

std::vector<ImageRead>* m_ptrReadImages;

I also have a global mutex defined, which I lock and unlock on each read/write operation to that shared container. What bothers me is that this mechanism is pretty obscure and sometimes I get confused whether the data is used by another thread or not.

So what is the more straightforward way to share this container between those threads?

Answer 1

The process you described as "Input-->preprocessing-->computation-->Output" is sequential by design: each step depends on the previous one so parallelization in this particular manner is not beneficial as each thread just has to wait for another to complete. Try to find out which step takes most time and parallelize that. Or try to set up multiple parallel processing pipelines that operate sequentially on independent, individual data sets. A usual approach for that would employ a processing queue which distributes the tasks among a set of threads.

Answer 2

It would seem to me that your reading and preprocessing could be done independently of the container.

Naively, I would structure this as a fan-out and then fan-in network of tasks.

First, make dispatch task (a task is a unit of work that is given to a thread to actually operate) that will create input-and-preprocess tasks.

Use futures as a means for the sub-tasks to communicate back a pointer to the completely loaded image.

Make a second task, the std::vector builder task that just calls join on the futures to get the results when they are done and adds them to the std::vector array.

I suggest you structure things this way because I suspect that any IO and preprocessing you are doing will take longer than setting a value in the vector. Using tasks instead of threads directly lets you tune the parallel portion of your work.

I hope that's not too abstracted away from the concrete elements. This is a pattern I find to be well balanced between saturating available hardware, reducing thrash / lock contention, and is understandable by future-you debugging it later.

Answer 3

I would use 3 separate queues, ready_for_preprocessing which is fed by InputStream and consumed by Pre-processing, ready_for_computation which is fed by Pre-Processing and consumed by Computation, and ready_for_output which is fed by Computation and consumed by OutputStream.

You'll want each queue to be in a class, which has an access mutex (to control actually adding and removing items from the queue) and an "image available" semaphore (to signal that items are available) as well as the actual queue. This would allow multiple instances of each thread. Something like this:

class imageQueue
{
    std::deque<ImageRead> m_readImages;
    std::mutex            m_changeQueue;
    Semaphore             m_imagesAvailable;

    public:
    bool addImage( ImageRead );
    ImageRead getNextImage();

}

addImage() takes the m_changeQueue mutex, adds the image to m_readImages, then signals m_imagesAvailable;

getNextImage() waits on m_imagesAvailable. When it becomes signaled, it takes m_changeQueue, removes the next image from the list, and returns it.

cf. http://en.cppreference.com/w/cpp/thread

Answer 4

Ignoring the question of "Should each operation run in an individual thread", it appears that the objects that you want to process move from thread to thread. In effect, they are uniquely owned by only one thread at a time (no thread ever needs to access any data from other threads, ). There is a way to express just that in C++: std::unique_ptr .

Each step then only works on its owned image. All you have to do is find a thread-safe way to move the ownership of your images through the process steps one by one, which means the critical sections are only at the boundaries between tasks. Since you have multiple of these, abstracting it away would be reasonable:

class ProcessBoundary
{
public:
  void setImage(std::unique_ptr<ImageRead> newImage)
  {
    while (running)
    {
      {
        std::lock_guard<m_mutex> guard;
        if (m_imageToTransfer == nullptr)
        {
          // Image has been transferred to next step, so we can place this one here.
          m_imageToTransfer = std::move(m_newImage);
          return;
        }
      }
      std::this_thread::yield();
    }
  }

  std::unique_ptr<ImageRead> getImage()
  {
    while (running)
    {
      {
        std::lock_guard<m_mutex> guard;
        if (m_imageToTransfer != nullptr)
        {
          // Image has been transferred to next step, so we can place this one here.
          return std::move(m_imageToTransfer);
        }
      }
      std::this_thread::yield();
    }
  }

  void stop()
  {
    running = false;
  }

private:
  std::mutex m_mutex;
  std::unique_ptr<ImageRead> m_imageToTransfer;
  std::atomic<bool> running; // Set to true in constructor
};

The process steps would then ask for an image with getImage() , which they uniquely own once that function returns. They process it and pass it to the setImage of the next ProcessBoundary .

You could probably improve on this with condition variables, or adding a queue in this class so that threads can get back to processing the next image. However, if some steps are faster than others they will necessarily be stalled by the slower ones eventually.

Answer 5

This is a design pattern problem. I suggest to read about concurrency design pattern and see if there is anything that would help you out.

If you wan to add concurrency to the following sequential process.

InputStream->Pre-Processing->Computation->OutputStream

Then I suggest to use the active object design pattern. This way each process is not blocked by the previous step and can run concurrently. It is also very simple to implement(Here is an implementation: http://www.drdobbs.com/parallel/prefer-using-active-objects-instead-of-n/225700095 )

As to your question about each thread sharing a DTO. This is easily solved with a wrapper on the DTO. The wrapper will contain write and read functions. The write functions blocks with a mutext and the read returns const data.

However, I think your problem lies in design. If the process is sequential as you described, then why are each process sharing the data? The data should be passed into the next process once the current one completes. In other words, each process should be decoupled.

Answer 6

You are correct in using mutexes and locks. For C++11, this is really the most elegant way of accessing complex data between threads.