Постановка задачи. Пусть мы имеем двух спортсменов-бегунов и тренера, фиксирующего в динамике число шагов, которые они пробежали на тот или иной момент времени. В целях простоты бегуны стартуют одновременно, бегут с одинаковой скоростью и длина шага у них одна. Необходимо создать программу, моделирующую поведение бегунов и их тренера.
Модель решения. Можно условиться, что спортсмен имеет счетчик шагов, который на каждом шаге увеличивается на единицу. Достигнув заданного числа шагов, "бегуны" останавливаются. "Тренер" в процессе бега отслеживает текущее значения счетчиков каждого спортсмена, выводя их значения на экран монитора (варианты - фиксирует в блокноте, записывает в текстовый файл на диск:).
На структурном уровне программа, реализующая поставленную задачу, содержит три параллельных не взаимодействующих между собой объекта (двух бегунов и одного тренера).
Программная реализация. Выделим для каждого объекта свой поток. Код класса модели спортсмена-бегуна может быть таким (Листинг 1):
#include "living_object.h"
class CDat;
class Trotter : public living_object
{
public:
Trotter(CDat *d, int num, long lSteps = 100000000);
virtual ~Trotter();
void run();
private:
CDat *pCDat;
int nNumTrotter;
};
Trotter::Trotter(CDat *d, int num, long lSteps):
living_object()
{
pCDat = d;
pCDat->nStepsAll = lSteps;
nNumTrotter = num;
}
Trotter::~Trotter() { }
void Trotter::run()
{
for (int i=1; i<=pCDat->nStepsAll; i++)
{
if (nNumTrotter ==0) {
pCDat->nCurStep0++;
}
else {
pCDat->nCurStep1++;
}
if (nNumTrotter ==0) {
if (pCDat->nStepsAll == pCDat->nCurStep0)
break;
}
else {
if (pCDat->nStepsAll == pCDat->nCurStep1)
break;
}
// Sleep(0);
}
}
Листинг 1. Код класса "бегуна".
Здесь класс living_object - базовый класс для любого, так называемого, активного/живого объекта на базе одного потока. Его код представляет Листинг 2.
Здесь метод run() реализует жизненный цикл активного объекта. В рамках его каждый объект-спортсмен в зависимости от своего номера - nNumTrotter наращивает в цикле значение соответствующего счетчика шагов. Первый объект изменяет счетчик nCurStep0, второй - nCurStep1. Когда значение счетчика шагов достигнет заданного числа - nStepsAll, объект завершает свою работу.
class living_object
{
static DWORD WINAPI HelperThreadProc(LPVOID p);
public:
living_object();
virtual void run() {};
virtual ~living_object() {};
};
extern HANDLE hStart;
extern CRITICAL_SECTION cs;
extern int total_threads;
extern DWORD endTick;
living_object::living_object()
{
DWORD threadID;
if(!CreateThread(NULL, 0, HelperThreadProc, (LPVOID)this, 0, &threadID))
printf("GetLastError: %d\n", GetLastError());
}
DWORD WINAPI living_object::HelperThreadProc(LPVOID p)
{
EnterCriticalSection(&cs);
total_threads++;
LeaveCriticalSection(&cs);
WaitForSingleObject(hStart, INFINITE);
((living_object*)p)->run();
EnterCriticalSection(&cs);
total_threads--;
endTick=GetTickCount();
LeaveCriticalSection(&cs);
return 0;
}
Листинг 2. Код класса базового активного объекта living_object .
Тренер, бегущий рядом с бегунами, имеет следующий код (Листинг 3):
#include "living_object.h"
class CDat;
class PrnCurStep : public living_object
{
public:
PrnCurStep(CDat *d);
virtual ~PrnCurStep();
void run();
private:
CDat *pCDat;
long lTmp0;
long lTmp1;
};
PrnCurStep::PrnCurStep(CDat *d):
living_object()
{
pCDat = d;
lTmp0= lTmp1= 0;
}
PrnCurStep::~PrnCurStep() { }
void PrnCurStep::run()
{
while (pCDat->nStepsAll != pCDat->nCurStep0)
{
// printf("%d %d\n", pCDat->nCurStep0, pCDat->nCurStep1);
///*
if (lTmp0 != pCDat->nCurStep0 || lTmp1 != pCDat->nCurStep1) {
printf("%d %d\n", pCDat->nCurStep0, pCDat->nCurStep1);
lTmp0 = pCDat->nCurStep0;
lTmp1 = pCDat->nCurStep1;
}
// Sleep(0);
//*/
}
}
Листинг 3. Код класса "тренер".
В рамках метода run "тренер" на каждой итерации цикла выводит на консоль текущие значения счетчика циклов обоих бегунов.
Тестирование. Запустив программу, моделирующую бегунов, мы получим результат, который показан на рис.1.
Рис. 1. Печать только изменений значения
Можно предположить, что в протоколе работы программы отражено только изменение значение счетчиков (см. также код "тренера"). Попробуем в этом убедиться:
Эксперимент 1. Внесем небольшое изменение в код "тренера", чтобы он выводил значения счетчиков "бегунов" на каждом шаге своей итерации. В результате получим следующий протокол работы программы, который представлен на рис. 2.
Рис. 2. Вывод на каждой итерации цикла печати.
Легко видеть, что, получив в свое распоряжение процессор, "тренер" выводит многократно текущие значения счетчиков шагов. Последние не изменяются, т.к. оба "бегуна" простаивают из-за того, что цикл процессора захвачен монопольно "тренером". По числу повторений можно определить число итераций, которые успевает сделать "тренер" в пределах выделенного ему времени процессора.
Эксперимент 2. Вставим в цикл "бегуна", прерывание, которое инициирует выход в ядро операционной системы (вызов функции Sleep с нулевым значение параметра "засыпания").
Так мы "насильно" изменим квантование процессора. Дело в том, что пропуски и/или повторы в отображении текущего значения счетчиков происходят потому, что "бегуны" успевают сделать достаточное число шагов, прежде чем тренер начнет выводить их текущее значение.
Примечание 1. То, что значения счетчиков разные на одном и том же шаге - такте дискретного времени, тоже непорядок. Ведь спортсмены начали бежать одновременно и бегут с одинаковой скоростью.
В результате получим протокол работы программы, который показан на рис.3. Из него видно, что теперь отображается каждый шаг бегуна/бегунов.
Рис. 3. Вставка Sleep в тело цикла "бегунов"
Примечание 2. Т.к. вывод данных резко увеличил время работы программы, то, чтобы оно имело приемлемое для нас значение, мы взяли меньшее число шагов (ср. время работы программы на рис. 1 и рис.3 с общим числом выполненных шагов). Кстати, так можно оценить время, затрачиваемое на вывод данных.
Однако, мы, оказывается, имеем лишь кажущееся благополучие, т.к. если вставить вызов Sleep в каждую итерацию цикла печати и немного увеличить заданное число шагов, то получим еще один протокол (рис. 4). Видно, что по каким-то причинам выводится значения до 66-го шага, а не все 100 шагов, как ожидалось.
Рис. 4. Вставка Sleep в тело цикла "тренера"
Эксперимент 3. Проведем эксперимент, запустив программу вне среды визуального проектирования. Два варианта исполняемых программных модули, созданных в проектах типа Release и Debug, при одном и том же значении максимального числа шагов показывают, как мы видим из протоколов, показанных на рис. 5, 6, разные "картинки". Более того, эти картинки отличаются и от результата работы программы под управлением среды проектирования, который ранее был представлен протоколом на рис.1.
Рис.5. Вне среды, режим Release
Рис.6. Вне среды, режим Debug
Эксперимент 4.. Совсем простой эксперимент: если мы повторно запустим программу, например, в режиме Debug, то увидим уже другие результаты работы. Они представлены на рис. 7
Рис.7. Повторный запуск (режим Debug).
Таким образом, последний эксперимент с многопоточной программой убеждает, что не надо даже и вносить изменения в программный код, чтобы получить результат работы программы, который отличается от предыдущего ее запуска.
Мир - удивителен! Но еще большее удивление можно испытать от непредсказуемой работы многопоточных программ! Зная об этом, с этим можно бороться тем или иным образом, но результат такой "борьбы" и есть то сложное и трудоемкое многопоточное программирование. Но самое опасное, что и это не дает полной гарантии от непредсказуемого (случайного) поведения подобных программ, поскольку такое поведение - одна из особенностей многопоточной модели параллельных вычислений.
