вопрос по потокам

[x77]

интересует механизм работы с глобальными переменными, будь то классы (типа TList), будь-то "классические" глобальные переменные, в частности, динамические массивы и массивы вариантов.

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

и ещё вопрос. как правильно организовать работу нескольких потоков с com-портом (чтение/запись)), будут ли там какие-либо грабли?

[Серж]

x77, по-моему, подходят все стандартные механизмы синхронизации:
критические секции, мутексы, семафоры, события, главное, чтобы потоки не писали одновременно, а что касается com-порта, то если все потоки читают в общий буфер и складывают в общий буфер для отправки, то тоже проблем не должно быть. Конечно, указатели буферов также должны быть глобальными переменными, а операции чтения-записи надо разделить по времени критическими секциями и т.п.

[Алексей++]

x77, самое простое - глобальный флаг. Если поток видит, что флаг установлен - работать с переменной низя. А сброшен - поток быстренько устанавливает флаг и работает. Потом сбрасывает

имхо

[x77]

Алексей1153,  я думал об этом. трабла в том, что может получиться так, что один поток всё время будет сбрасывать и ставить этот флаг, блокируя работу других потоков. и здесь остаются два варианта: общий буфер на чтение/запись, как предлагает Серж, или очередь потоков: глобальная переменная, массив, в котором потоки просто тупо засовывают в конец свой ThreadId. работает только тот поток, который находится в списке первым. отработав, он удаляет себя из списка, очередь "сдвигается". так можно гарантировать, что каждый поток отработает своё именно в порядке возникновения необходимости отработать.

но меня в этом смущает другое: по сути это всё механизмы превратить многопоточные приложения в одно-поточное, китайский коммунизм. какой смысл связываться с несколькими потоками, если в конечном итоге всё равно в данный момент времени будет отрабатывать только один. выходит, что работать с комами и глобальными переменными именно в потоках, т.е. одновременно, нельзя? так может тогда проще и не связываться с ними вообще?

[Серж]

x77, выигрыша все же можно добиться, если использовать асинхронные запись/чтение, тогда каждый поток ждет только окончания операции, но не полностью выполнения всей операции ввода-вывода.

[x77]

Серж, можно подробнее про асинхронные чтение/запись? я просто делал CeateFile/OpenFile и дальше работал с хэндлом, как с обычным файловым дескриптором. насколько я понимаю, асинхронностью здесь не пахнет?

[Серж]

x77, функцию CreateFile нужно вызвать, добавив в предпоследний параметр флаг FILE_FLAG_OVERLAPPED. Затем нужно создать две структуры типа OVERLAPPED для чтения и записи. В этих структурах содержатся эвенты, сигнализирующие об окончании операции ввода-вывода. Функции ReadFile и WriteFile запускаются с указанием адресов этих структур в последнем параметре. После вызова управление мгновенно передается следующему оператору программы. В отдельных потоках с помощью функций WaitForSingleObject или WaitForMultipleObjects и т.п. отслеживаются эвенты из структур OVERLAPPED.

[Серж]

x77, забыл еще добавить, что события в OVERLAPPED нужно создать с помощью CreateEvent.

[Серж]

x77, еще вдогонку, сразу не нашел ссылку. В MSDN есть статья, которая называется "Serial Communications in Win32", автор Allen Denver, там подробно описывается этот механизм применительно к com-порту.

[x77]

Серж, т.е. отселживать эти евенты возможно и из других потоков, не только из потоков, создавших эти структуры? я могу, к примеру, организовать работу так, чтобы по факту возникновения в порте пакета срабатывал какой-то евент, т.е., фактически, уйти от непрерывного опроса порта?

[Серж]

x77, да, конечно, нужно хэндлы создать в основной программе и либо сделать их глобальными, либо передать каким-нибудь другим способом в каждый поток.

[x77]

всем спасибо, бум пробовать.

[KiborK]

А как вам такая идея:
допустим есть процес А и процес Б которые будут писать и читать данные в одну переменную... Ну так разрешу себе перефразировать задачу: Есть устройство ввода вывода и два приложения ктоторым нужен доступ к ним. Ну так какое стандарное решение, создаем процес В который будет драйвером а интерфейс реализуем через WinAPI. тоесть хандле в процессе драйвере получает сообщение на запрос о чтении\заиси и возврат информацыи через сообщение на нужный хандле. Так получается что недопустимые функцыи процессы выполняют по порядку о все остальное одновременно

[x77]

KiborK, согласен, но это усложнённый вариант 2: по сути, та же очерёдность потоков. смысл многопоточности теряется, т.к. в каждый отдельно взятый момент с устройством будет работать только один поток. а будет он выделенным специально для этого, или будет действовать принцип очерёдности - это уже дело техники.

не совсем понял, что значит "хандл в процессе драйвере получает сообщение". хандл - это просто несколько байтов, не более. можно подробнее, каким образом в процессе обмена данными участвуют дескрипторы?

[Алексей++]

x77, а чем мутексы не устраивают, особенно если потоки разные?
это по сути те же флаги...

но меня в этом смущает другое: по сути это всё механизмы превратить многопоточные приложения в одно-поточное, китайский коммунизм. какой смысл связываться с несколькими потоками, если в конечном итоге всё равно в данный момент времени будет отрабатывать только один. выходит, что работать с комами и глобальными переменными именно в потоках, т.е. одновременно, нельзя? так может тогда проще и не связываться с ними вообще?

ну так ОДИН поток (суть главный процесс) по определению не может сразу с двух сторон к переменной подбираться! В одном потоке гарантированно не будет накладок

 :arrow:
кстати, пример с мутексами (на си, правда, но думаю - и так понятно) :

Код:

#include "AFXMT.H"

UINT thread1(LPVOID p)
{
  //создаём мутекс с именем stop
  CMutex m(0,"stop");

   //на этом участке коданадо синхронизировать
   m.Lock(INFINITE);//блокировка(на бесконечное время)
   ...
   ...
   m.Unlock();//участок завершён, разблокировка

   //некритичный участок кода
}

Код:

UINT thread2(LPVOID p)
{
  //создаём мутекс тоже с именем stop
  CMutex m(0,"stop");

   //на этом участке коданадо синхронизировать
   m.Lock(INFINITE);//блокировка(на бесконечное время)
   ...
   ...
   m.Unlock();//участок завершён, разблокировка

   //некритичный участок кода
}

то есть мутекс "stop" управляет доступам ко всем критическим кускам кода, которые блокированы вызовом его Lock. Если при вызове Lock како-либо поток уже имеет доступ к участку , то новый поток блокируется, пока тот, более ранний поток, не освободит by Unlock(). И наоборот.

 :arrow:
кстати, у Lock() такой прототип:
virtual BOOL Lock(DWORD dwTimeout = INFINITE);

то есть можно задать бесконечное время блокировки (что будет и по умолча), а можно задать конкретное время (полагаю - в мс). И по истечению времени Lock() вернёт False, если поток так и не получил доступ.

 :arrow:

трабла в том, что может получиться так, что один поток всё время будет сбрасывать и ставить этот флаг, блокируя работу других потоков.

так он же всё равно должен давать время другим потокам иначе - какая же энто нафиг многозадачность! На крайняк - вставь в этот поток маленький тормоз типа

for(UINT i =100;i;i--);

[x77]

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

[Серж]

x77, всюду, где программа может вылететь, например, при работе с файлами, нужно обрабатывать исключения( try finally)  и по finally освобождать мьютексы.

[x77]

Серж, это не гарантирует освобождения мьютекса. представь, что программу просто выключили. i.e. - сняли процесс. я не уверен, что finally отработает.

[Серж]

x77, если программу сняли, то убьются все потоки, ею запущенные,
думаю закроются и мьютексы, в худшем случае какой-нибудь мусор останется в памяти.

[Алексей++]

x77, а энто не поможет? :

кстати, у Lock() такой прототип:
virtual BOOL Lock(DWORD dwTimeout = INFINITE);

можно же время задать - секунд пять, а потом, если из лока вылетело FALSE - реагировать соответственно...

А на крайняк - вспоминаем флаги - я не знаю, как там в системе устроены мутексы, но по сути - это всё эти несчастные флаги...

[Алексей++]

реагировать соответственно...

например запускать вспомогательный экзешник, который убьёт этот и перезапустит заново. Если так можно

[Серж]

x77, я попробовал под Win2K, от мьютексов после принудительного закрытия не остается никаких следов, даже от именованных, т.е. система сама их освобожлает.
А откуда такая информация о мьютексах?

[x77]

Серж, а ты полностью весь механизм синхронизации прогнал, или просто создавал несколько мьютексов в одном процесе? при синхронизации через мьютексы тебе придётся делать DuplicateHandle, чтобы получить доступ к мьютексу из другого процесса. мьютекс автоматически уничтожается, когда уничтожены все его дескрипторы. вот это меня и насторожило. если при аварийном завершении останется "мусор" в виде чьих-то хендлов, то по идее, освобождения мьютекса не произойдёт.  может я не прав, конечно, винапи не самая моя сильная сторона, но как-то связываться всё-равно не хочется

[Серж]

x77, не надо бояться мьютексов. Единственное, что возникает при работе, если поток, который владеет мьютексом, прерывается без освобождения, так это то, что в фунции WaitFor... в другом потоке возникает
код возврата WAIT_ABANDONED, который как раз и сигнализирует об этой ситуации, по этому коду можно как раз диагностировать ситуацию, но ни о каком зависании речи и быть не может.

[Алексей++]

я провёл такой эксперимент:

Код:

WORD var;

UINT t1(LPVOID p)
{
	CMutex m1(0,"m1");

	for(;;)
	{
		if(m1.Lock(10*1000)==FALSE)
		{
			::AfxMessageBox("облом");
			return 0;
		}
		(*((WORD*)p))++;
		m1.Unlock();
	}
}

Код:

UINT t2(LPVOID p)
{
	CMutex m1(0,"m1");
	for(;;)
	{
		m1.Lock();
		for(;;);
		m1.Unlock();
	}
}

Код:

void CGuard2View::OnButton1() 
{
	::AfxBeginThread(t1,&var);
	::AfxBeginThread(t2,&var);
}

то есть один поток (t2) включает мутекс и вешает систему, а другой, прождав 10 секунд, говорит об обломе. Причём при этом запущен монитор цп. Цп - на 100% занят. А когда закрываю прогу - всё смолкает, 0% загрузки

[x77]

Серж, Алексей1153, убедили , спасибо.