Я познаю мир. Многопоточность.

Если все блокировать, то никакой многопоточки не получится. Я бы тогда сделал области непересекающимися и для каждой области свой локальный набор данных. Тогда никаких (почти) блокировок и не потребуется.

Попробуй для начала обернуть те массивы в mutex/spinlock/rwlock в зависимости от способа доступа. Блокировать надо то, что вместе читается-пишется, очевидно.

Видимо все-таки не получится сделать то, чего хочется. Проблема в том, что локально сделать это все не выйдет (на данном этапе). А если блокировать, то все потоки будут ждать один, пока он не закончит свою работу, так как блокировать придется весь массив. В общем смысла нет. Буду думать как это все переделать. Всем спасибо.

Добиться того что бы обработчики изображений не влияли своей работой друг на друга.

Что значит класс меняет состояние? У тебя там что статические поля используются или глобальные переменные?

В том-то и дело, что пока я не знаю как это сделать. Каждый проход (обработка одной области), по задумке, меняет состояние элементов массива в зависимости от его начального состояния. Просто изначально, из-за отсутствия опыта, о многопоточности не подумал, со всеми вытекающими отсюда последствиями.

Добиться того что бы обработчики изображений не влияли своей работой друг на друга.

Плюсую, перед тем как что-то блокировать, нужно сначала разнести задачи так, чтоб они работали либо каждая со своими данными, либо с общими, но неизменяемыми данными. И в одном из отдельных потоков уже ждать окончание/складывать результаты.

Посмотрите на то, как с помощью Intel Threading Building Blocks делается распараллеливание потоков данных: Parallelizing Data Flow and Dependence Graphs. Может подтолкнет в правильном направлении.

Каждый проход (обработка одной области), по задумке, меняет состояние элементов массива в зависимости от его начального состояния

А скопировать именно эту область перед обработкой слишком затратно?

Что-то вроде того. В классе есть массив. Вот его значения и меняются после каждого вызова одного из его методов. Причем меняются в зависимости от значения его элементов до вызова этого метода. Порочный круг в общем.

Что-то вроде того. В классе есть массив. Вот его значения и меняются после каждого вызова одного из его методов. Причем меняются в зависимости от значения его элементов до вызова этого метода. Порочный круг в общем.

Думай в понятиях потоков, а не классов. Если не хочется глобальной переделки кода, сделай несколько объектов (пул) второго класса, каждый со своим рабочим потоком и грузи свободные объекты из пула, передавая копию изображения. Все статические поля и методы 2-го класса заменить на обычные.

К примеру, у меня есть три массива(positives, negatives, posteriors) размером array_size. Вот кусочек псевдокода с примерной логикой:

void classify(frame, ROI)
{
    int value = some_function(frame, ROI);
    for (int i = 0; i < array_size; i++) {
        if (value >= some_vale) {
            positives[i]++;
        } else {
            negatives[i]++;
        }
        if (positives[i] > 0) {
            posteriors[i] = positives[i] / (positives[i] + negatives[i]);
        }
    }
}

Спасибо, обязательно почитаю.

Вот этот кусок, я так понимаю, и нужно блокировать. Но тогда другие потоки будут ждать один и весь смысл распараллеливаня пропадает.

http://doc.qt.io/qt-5/qtcore-threads-mandelbrot-example.html

Не видно тут зависимостей, возможно тебе просто атомарные инкременты нужны? Если атомарность нужна на все три массива одновременно, и они фигурируют в some_function(), то действительно нечего распараллелить.

Если там циклы во все поля, возможно, некоторый профит можно получить малой кровью с использованием openmp.

напиши перед циклом

#pragma omp parallel for shared(positives, negatives, posteriors) private(i)

Да, openmp ускорило. Не совсем то, чего хотелось, но тоже вариант. Спасибо.

openmp

Фу, какая дрянь, лучше брать GCD

А во сколько раз?

Специально не замерял, но в 3 раза точно (до этого обрабатывало примерно 6 кадров в секунду, теперь 18, но тут уже ограничение используемой камеры — это максимум, который она может выдать).