Question

I am creating an application which displays the market data and uses it in some other forms too. I store market data in a map say
std::map<tickerId, StockData>. Let me give one used case of how this map can be used.

1. network sends a data packet encapsulating the stock Data at time t. updatePrice(tickerId, latestPrice)
2. update the stock data in the map. Now, multiple threads can access/update the data. So the map has to be locked for thread-safe operations. Here is the first question, do I need to lock the underlying data too for updates?
3. There are multiple uses of the new stock data, say, there is a price update on IBM, then I need to update the value of IBM in my portfolio. As well as display the new data on a screen. And there can be several other simultaneous uses.updatePosition(tickerId, price) and updateStockScreen(tickerId, price). Also, separting Gui updates from position update is important as GUI is not the main strength of the application.
4. I am just troubled about how to implement this type of design. I read about Model/View Design in QT to display data but if View thread reads from the same map, it has to be locked. This leads to an slow/inefficient design. Every time view reads from the model, the model needs to be locked. Is this preffered in real-time GUIs?
5. To summarize, I have stored a lot of different objects as maps. And objects are updated in realtime. I need to update them and then use them at various locations. It would be great if someone can give me a small example on how to implement such designs.

Some references to useful books are appreciated too.

I am new and trying to achieve too much with my little knowledge so forgive me if I have asked stupid/ill-formed questions.

Thanks
Shiv

Answer 1

It sounds conceptually like you want the model on one thread and the view on another, which I looked into at one point.

If so…and your model is read-only through the view widget then yes, you have to lock. I’d argue that doing so undermines the elegance of the “decoupling” provided by the model/view separation. But it could be made to work.

However…if your model is read-write through the view it’s not possible to do correctly at all because of the queued nature of the notification slots. Here’s an archive of a mailing list conversation I had on the qt-interest mailing list on the topic:

http://blog.hostilefork.com/qt-model-view-different-threads/

“The short version is that I don’t think it’s feasible for a Model to
be modified on a non-GUI thread…regardless of whether the model’s
data has been protected with read/write locks. If what I’m gathering
is correct, then Qt should probably have an assert that a model and
its view have the same thread affinity (it doesn’t seem to do that now)”

A subsequent unit test by a KDE developer verified this.

I feel the best way to work around this is to keep the model and the view on the same thread, and only modify the model in the GUI thread. So if the worker thread wishes to change it then it should use a signal.

Whether the worker needs to keep their own copy of the data from which the model was created (or if it needs to get notifications to keep that up to date when the user changes the model through the view) depends on your app. If I understand you correctly, it sounds like like you could probably get away with just ferrying the updates through signal/slots and forgetting them on the worker…