Создание сайта, дизайн, web дизайн
Главная Работы Услуги Цены Контакты

 Главная
 Работы
 Услуги
 Цены
 Контакты
 

В современном операционном окружении программист не может быть уверен и не должен полагаться на то, что коды его программы будут выполняться в тон же последовательности, в какой они написаны. Выполнение одной из функций программы может быть остановлено системой и возобновлено позднее, причем это может произойти даже при выполнении тела какого-либо цикла. При проектировании многопотоковых приложений следует иметь в виду, что ресурсы, разделяемые потоками (блоки памяти или файлы), можно неосознанно повредить. Чтобы показать, как это происходит, рассмотрим пример, который приведен в книге Jesse Liberty «Beginning Object-Oriented Analysis and Design with C++» (Дж. Либерти «Начало объектно-ориентированного анализа и проектирования с помощью C++»), доступной в MSDN.

Представьте себе пассажирский авиалайнер в полете, а в нем такой разделяемый всеми ресурс, как туалетная комната. Создатели самолета предполагали, что только одна персона может занимать эту комнату. Первый, кто ее занял, закрывает (lock) доступ к пей для всех остальных. Следующий пассажир, желающий воспользоваться этим ресурсом, может либо терпеливо ожидать освобождения, либо по истечении какого-то времени (time out) вернуться на свое сиденье и продолжать заниматься тем, чем он был занят до этого события. Решение о том, что выбрать и как долго ждать, принимает пассажир. Блокирование ресурса порождает неэффективное проведение времени второго пассажира как ожидающего очереди, так и избравшего другую тактику.

Возвращаясь к многопотоковым процессам, отметим, что если не блокировать ресурс, то становится возможным повреждение данных. Представьте, что один поток процесса проходит по записям базы данных, повышая зарплату каждому сотруднику на 10%, а другой поток в это же время изменяет почтовые индексы в связи с введением нового стандарта. Согласитесь с тем, что разумно совместить эти две работы в одном процессе с целью повышения производительности. Что может произойти, если не блокировать доступ к записи при ее модификации? Первый поток прочел запись (все ее поля), и занят вычислением повышения (предположим, с $80 000 до $85 000). В это время второй поток читает эту же запись с целью изменения почтового индекса. В этой ситуации может произойти следующее: первый поток сохраняет измененную запись с новым значением зарплаты, а второй, возвращая запись с измененным индексом, реставрирует значение зарплаты и данный сотрудник останется без повышения. Это происходит по причине того, что оба потока не могут обратиться к части записи и поэтому работают со всей записью, хотя модифицируют только отдельные ее поля.

Стратегии решения проблемы

Для того чтобы исключить подобный сценарий, автор многопотокового приложения должен решать проблему синхронизации при попытке одновременного доступа к разделяемым ресурсам. Если говорить о файлах с совместным доступом, то сходная ситуация может возникнуть и при столкновении различных процессов, а не только потоков одного процесса. Разработчика в этом случае уже не устроит стандартный способ открытия файла. Например1:


//======= Создаем объект класса CFile


CFile file;


// ====== Строка с именем файла


CString fn("MyFile.dat");


//===== Попытка открыть файл для чтения


if ( ! file.Open(fn,CFile::modeRead))


{


MessageBox ("He могу открыть файл "+fn, "Ошибка");


return;

}


Он должен писать код с учетом того, что файл может быть заблокирован какое-то время другим процессом. Если следовать уже рассмотренной тактике ожидания ресурса в течение какого-то времени, то надо создать код вида:


bool CMyWnd::TryOpen()


<


//====== Попытка открыть файл и внести изменения


CFile file;


CString fn("MyFile.dat"), Buffer;


//===== Флаг первой попытки

static bool bFirst = true;


if (file.Open (fn, CFile:: modeReadWrite I CFile::shareExclusive))


{


// Никакая другая программа не сможет открыть


// этот файл, пока мы с ним работаем


int nBytes = flie.Read(Buffer,MAX_BYTES);


//==== Работаем с данными из строки Buffer

//==== Изменяем их нужным нам образом


//==== Пришло время вновь сохранить данные

file.Write(Buffer, nBytes);


file. Close ();


//==== Начиная с этого момента, файл доступен

//==== для других процессов

//==== Если файл был открыт не с первой попытки,

//==== то выключаем таймер ожидания

if (IbFirst)


KillTimer(WAIT_ID);


//===== Возвращаем флаг успеха

return bFirst = true;


}


//====== Если не удалось открыть файл


else


if (bFirst) // и эта неудача — первая,

//===== то запускаем таймер ожидания

SetTiraer(WAIT_ID, 1000, 0);


//===== Возвращаем флаг неудачи


return bFirst = false;

}


В другой функции, реагирующей на сообщения таймера, называемой, как вы знаете, функцией-обработчиком (Message Handler), надо предусмотреть ветвь для реализации выбранной тактики ожидания:


//====== Обработка сообщений таймера


void CMyWnd::OnTimer(UINT nID)

{


//====== Счетчик попыток


static int iTrial = 0;


//====== Переход по идентификатору таймера


switch (nID)


{


//== Здесь могут быть ветви обработки других таймеров


case WAIT_ID:


//====== Если не удалось открыть


if (ITryOpenO)


{


//===== и запас терпения не иссяк,


if (++iTrial < 10)


return; // то продолжаем ждать


//=== Если иссяк, то сообщаем о полной неудаче

else

{


MessageBox ("Файл занят более 10 секунд",


"Ошибка"); //====== Отказываемся ждать


KillTimer(WAIT_ID);


//====== Обновляем запас терпения


iTrial = 0;

}

}

}

}


Существуют многочисленные варианты рассмотренной проблемы, и в любом случае программист должен решать их, например путем синхронизации доступа к разделяемым ресурсам. Большинство коммерческих систем управления базами данных умеют заботиться о целостности своих данных, но и вы должны обеспечить целостность данных своего приложения. Здесь существуют две крайности: отсутствие защиты или ее слабость и избыток защиты. Вторая крайность может создать низкую эффективность приложения, замедлив его работу так, что им невозможно будет пользоваться. Например, если в примере с повышением зарплаты первый поток заблокирует-таки доступ к записи, но затем начинает вычислять новое значение зарплаты, обратившись к источнику данных о средней (в отрасли) зарплате по всей стране. Такое решение проблемы может привести к ситуации, когда второй поток процесса, который готов корректировать эту же запись, будет вынужден ждать десятки минут.


Одним из более эффективных решений может быть такое: первый поток читает запись, вычисляет прибавку и только после этого блокирует, изменяет и освобождает запись. Такое решение может снизить время блокирования до нескольких миллисекунд. Однако защита данных теперь не сработает в случае, если другой поток поступает также. Второй поток может прочитать запись после того, как ее прочел первый, но до того, как первый начал изменять запись. Как поступить в этом случае? Можно, например, ввести механизм слежения за доступом к записи, и если к записи было обращение в интервале между чтением и модификацией, то отказаться от модификации и повторить всю процедуру вновь.

Примечание

Каждое решение создает новые проблемы, а поиск оптимального баланса ложится на плечи программиста, делая его труд еще более интересным. Кстати, последнее решение может вызвать ситуацию, сходную с той, когда два человека уступают друг другу дорогу. Отметьте, что решение вопроса кроется в балансе между производительностью (performance) и целостностью данных (data integrity).

 

 

Афоризм дня:
Говорите правду - и вы будете оригинальны.
А.В. Вампилов
© 2004-2017 LABDESIGN.RU   e-mail: