Блог

У меня есть библиотека с IJobMaker сущностью, которая создает определенное количество IJob объектов для запуска в собственных потоках, управляемых пользователем. Для отслеживания прогресса каждого IJob я внедряю шаблон observer с IProgressObserver в каждом задании. Трудность возникает, когда я хочу сообщить об ОБЩЕМ прогрессе.

Идеальным для меня было бы иметь IProgressOverserver.ReportProgress(float jobProgress, float overallProgress , который сообщает как о работе, так и об общем прогрессе. IJobMaker может быть осведомлен о части каждого задания в общей работе и каким-то образом собирать отчеты каждого.

Возникают два основных вопроса:

1. Механизм синхронизации? Держать мьютекс внутри IJobMaker , например, может повредить производительность, поскольку IProgressOverserver.ReportProgress вызывают большое и мьютекс может повлечь за собой переключение контекста, а что нет. InterlockedIncrement выглядит как хороший вариант, но поскольку такой функции для с плавающей запятой нет, я был бы вынужден сообщать о прогрессе с помощью целых приращений. (Я бы хотел держаться подальше от функций c 0x или Boost)

2. Шаблон проектирования? IJob о прогрессе сообщается из его самых глубоких алгоритмов. Мне нужен каждый такой отчет как для связи с центральным объектом для вычисления общего прогресса, так и для вызова IProgressObserver.ReportProgress метода, который находится в IJob .

Пара предложений по потоковой обработке:

1. Не сообщайте о каждом малейшем прогрессе. Сообщать основному потоку только после достижения определенного заранее определенного уровня прогресса, или по истечении определенного заранее определенного количества времени, или по завершении подзадачи. Это может значительно сократить объем синхронизации.
2. Если вы реализуете # 1, мьютекс может работать довольно хорошо.
3. Если мьютекс окажется слишком дорогим, вы можете сообщить о прогрессе, используя атомарную целочисленную переменную: просто масштабируйте значения от «нет прогресса» до «все сделано» до 0 … INT_MAX .

Что касается проектирования API, не должно быть слишком сложно придумать что-то разумное. Моим общим советом было бы не перепроектировать его.

Прежде всего, довольно плохая практика использовать значения с плавающей точкой в таких случаях. Используйте целое число.

Есть еще одно предложение. Вы можете использовать сегментацию — синхронизировать только несколько потоков с помощью одного мьютекса / атома (один сегмент). А затем соберите общее количество по всем сегментам.

Кроме того, есть хорошее место, чтобы начать изучать высокопараллельные алгоритмы:http://www.1024cores.net/home/lock-free-algorithms

UDPATE Есть пример проблем с float

 #include <iostream>
using namespace std;
int main() {
    float f = 0;
    for(int i=0; i<100000-98;   i)
    {
        f  = 0.00001;
    }
    cout << f << endl;
}
  

Итак, если у вас есть 100 заданий с 1000 шагами в каждом, вы получите результат 1.0 в 98 раньше, чем вы могли ожидать.