views:

166

answers:

1

I have four threads in a C++/CLI GUI I'm developing:

  1. Collects raw data
  2. The GUI itself
  3. A background processing thread which takes chunks of raw data and produces useful information
  4. Acts as a controller which joins the other three threads

I've got the raw data collector working and posting results to the controller, but the next step is to store all of those results so that the GUI and background processor have access to them.

New raw data is fed in one result at a time at regular (frequent) intervals. The GUI will access each new item as it arrives (the controller announces new data and the GUI then accesses the shared buffer). The data processor will periodically read a chunk of the buffer (a seconds worth for example) and produce a new result. So effectively, there's one producer and two consumers which need access.

I've hunted around, but none of the CLI-supplied stuff sounds all that useful, so I'm considering rolling my own. A shared circular buffer which allows write-locks for the collector and read locks for the gui and data processor. This will allow multiple threads to read the data as long as those sections of the buffer are not being written to.

So my question is: Are there any simple solutions in the .net libraries which could achieve this? Am I mad for considering rolling my own? Is there a better way of doing this?

+1  A: 

Is it possible to rephrase the problem so that:

  1. The Collector collects a new data point ...
  2. ... which it passes to the Controller.
  3. The Controller fires a GUI "NewDataPointEvent" ...
  4. ... and stores the data point in an array.
  5. If the array is full (or otherwise ready for processing), the Controller sends the array to the Processor ...
  6. ... and starts a new array.

If the values passed between threads are not modified after they are shared, this might save you from needing the custom thread-safe collection class, and reduce the amount of locking required.

richj
You're correct in your re-iteration my question. The data is not changed once the controller has performed a quick bit of filtering.Your suggestion might work, but the GUI would need a copy of the data points as well as the background processor. I guess I was just worried I'd be allocating and deallocating memory all over the place. I could start with that though and profile it to see if sending copies of the data all over the places slows things down..
Jon Cage