Can two threads read from the same QList at the same time?

Question

Pretty new to threading and I have this QList that the threads share between them. They all have their own space that they can work on, and the GUI (the model/view) access t

Answer 1

I realize that its possible to pre-allocate a QList and let threads operate on different areas of that list, but in my opinion I think its a bad pattern to follow.

When I work with Qt (I actually work with PyQt since I'm a python programmer), I feel its best to make use of the signal/slot mechanism that is provided to you and never share memory between threads. Each thread should be given its own data either directly at creation, or over time through a queue that is waits on. When it is done with its work or a chunk of work it can emit a signal with the data. You would have a single handler that connects to all of your threads to listen for data to be ready.

The result of this pattern is that you aren't sharing memory and you don't have to worry so much about locks, but rather just waiting for workers to signal their data is ready, and a single handler is collecting and updating the main model.

That being said, here is another reference of someone using a QList as shared memory and experiencing crashes until they locked it: http://developer.qt.nokia.com/forums/viewthread/13049

I think when people (myself included) first start working with thread the immediate impulse is to just use containers the same way they always have. But once you start threading you immediately already increase both the complication of the codes logic as well as the capacity for bugs. Synchronization of shared memory is one way to approach it, using mutexes to lock resources before access. But I think its worth mentioning another way which is communicating.

Googles Go language was built with one of its core principles being: "Dont communicate by sharing memory; share memory by communicating" http://golang.org/doc/codewalk/sharemem/

Go wanted to address this issue at its core by communicating memory over channel objects, which resemble signal/slot in Qt. One component has exclusive local access to memory and then pass it along to another component over a channel. This gurantees you wont have race conditions. Anyways just thought I would tack on this extra reference because I feel its very relevant to thread programming issues.