有人如何在不阻塞主事件循环的情况下从不同的线程访问在主事件循环中创建的 QObject？

Question

In my scenario, I have a complicated QObject* and QQuickItem* hierarchy set up with many child objects which are all critical to the application.

What I wish to accomplish is:

Perform a complex, cpu-intensive operation from a specific QObject-inhereted type. This operation must access properties from many of the different QObjects in the hierarchy and would require a large amount of memory being copied and parsed by the separate thread (to the point where it is more efficient to simply block the main event loop than to copy everything over).

Is there a way to directly access the QObjects that are children of the main QObject which creates a new thread?

Let me clarify a little bit with some code:

This snippet is responsible for finding the neighboring blocks in a grid of blocks that match certain conditions (it is my cpu intensive operation because it needs to be performed many times in a short timespan)

QList<QQuickItem *> Blockgrid::find_neighbors(QQuickItem *startItem, QList<QQuickItem *> currentNeighbors, QQuickItem *currentItem)
{
  QList<QQuickItem*> neighbors;
  QList<QQuickItem*> new_neighbors;
  Blockrow* startRow = this->get_item_row(startItem);
  int startCell = startRow->get_cell_number(startItem);
  int startColor = startItem->property("blockColor").toInt();
  Blockrow* currentRow = this->get_item_row(currentItem);
  int currentCell = currentRow->get_cell_number(currentItem);
  QList<QQuickItem*> potential_neighbors;
  QQuickItem* topNeighbor = this->find_block(currentRow->rowNumber() - 1, currentCell);
  QQuickItem* bottomNeighbor = this->find_block(currentRow->rowNumber() + 1, currentCell);
  QQuickItem* leftNeighbor = this->find_block(currentRow->rowNumber(), currentCell - 1);
  QQuickItem* rightNeighbor = this->find_block(currentRow->rowNumber(), currentCell + 1);
  if (topNeighbor != nullptr) {
      potential_neighbors << topNeighbor;
    }
  if (bottomNeighbor != nullptr) {
      potential_neighbors << bottomNeighbor;
    }
  if (leftNeighbor != nullptr) {
      potential_neighbors << leftNeighbor;
    }
  if (rightNeighbor != nullptr) {
      potential_neighbors << rightNeighbor;
    }
  foreach (QQuickItem* potentialItem, potential_neighbors) {
      if (potentialItem->property("blockColor") == startColor) {
          if (potentialItem != currentItem) {
              if (!neighbors.contains(potentialItem)) {
                  new_neighbors << potentialItem;


                }
            }
        }
    }

  QList<QQuickItem*> final_neighbors;


  if (new_neighbors.count() > 0) {
      final_neighbors << currentNeighbors;
      foreach (QQuickItem* neighborItem, new_neighbors) {

          if (!final_neighbors.contains(neighborItem)) {
              QList<QQuickItem*> send_neighbors;
              send_neighbors << currentNeighbors << neighborItem << this->find_neighbors(startItem, send_neighbors, neighborItem);
              foreach (QQuickItem* sendItem, send_neighbors) {
                  if (!final_neighbors.contains(sendItem)) {
                     final_neighbors << sendItem;
                    }
                }
            }
        }
    }

  return final_neighbors;
}

---

What is important is not the CPU intensive code, which is merely there to provide some context as to the complexity of the operation.

What I am trying to accomplish is running the method detect_matches in a separate thread:

---

 class Worker : public QObject
  {
      Q_OBJECT

  public slots:
      void detect_matches(Blockgrid* i_grid)
       {
        for (int row=0; row<i_grid->numberOfRows; row++) {
            for (int col=0; col<i_grid->numberOfRows; col++) {
                i_grid->find_block(row, col)->setProperty("opacity", 1.0);
              }
          }
        for (int row=0; row<i_grid->numberOfRows; row++) {
            for (int col=0; col<i_grid->numberOfRows; col++) {
                QList<QQuickItem*> currentNeighbors;

                QList<QQuickItem*> matches;
                matches <<  i_grid->find_neighbors(i_grid->find_block(row,       col), currentNeighbors, i_grid->find_block(row, col));
                if (matches.count() >= 3) {
                    foreach (QQuickItem* matchItem, matches) {
                       matchItem->setProperty("launched", true);
                       i_grid->find_block(row, col)->setProperty("launched",true);


                      }

                  }

              }
          }

      }

   }


};

---

This thread is started using the moveTothread technique:

---

 void Blockgrid::find_matches() {

      Worker *worker = new Worker;
      worker->moveToThread(&workerThread);

      worker->detect_matches(this);

 }

Is there a way to make this work? Currently the Worker thread cannot interact with the objects that live in the Blockgrid object once it has been moved to a separate thread..

Like I said before, copying all of the data from the Blockgrid class into the Worker thread would essentially require more CPU and processing time than the time that the thread would take to finish computation, which is why I wish to find a technique that will allow for accessing objects across threads.

Thanks.

Answer 1

You could construct your QObject's with a parent, then access the children of the main QObject. Every class that inherits from QObject should implement a constructor that takes a parent QObject*.

QObject *main = new QObject();
QObject *child1 = new QObject(main);
QObject *child2 = new QObject(main);

If you keep main somewhere you can access it, you can just iterate over its children.

https://doc.qt.io/qt-5/qobject.html#children

foreach (QObject *child : main->children()) {
    // do your stuff with each child
    foreach (QObject *grandChild : main->children()) {
        // do your stuff with each grandchild            
    }
}

Answer 2

The constructor of your Worker class should take a pointer to the shared object; and then the Worker class should perform activities with this injected shared object.

In this way you can control which Worker thread will use which shared object. Also, need to take care of data sync via mutex.