Текущий архив: 2011.04.17;
Скачать: CL | DM;
Вниз
Организация многопоточности Найти похожие ветки
← →
Leonid Troyanovsky © (2009-08-17 13:29) [40]
> Kolan © (17.08.09 13:15) [39]
> Что такое TRTLCriticalSection? В справке нет.
From Turbo Delphi for Win32 help:
TRTLCriticalSection stores information about a Windows critical section.
From Windows.pas (find declaration):
TRTLCriticalSection = _RTL_CRITICAL_SECTION; // &etc.
--
Regards, LVT.
← →
Kolan © (2009-08-17 16:15) [41]Благодарю.
А чем принципиально исользованиеTRTLCriticalSectionотличается от использованияTCriticalSection?
Кстати в 2009 Делфи для этого типа есть два хелпера:TCriticalSectionHelper = record helper for TRTLCriticalSection
procedure Initialize; inline;
procedure Destroy; inline;
procedure Free; inline;
procedure Enter; inline;
procedure Leave; inline;
function TryEnter: Boolean; inline;
end;
TConditionVariableHelper = record helper for TRTLConditionVariable
public
class function Create: TRTLConditionVariable; static;
procedure Free; inline;
function SleepCS(var CriticalSection: TRTLCriticalSection; dwMilliseconds: DWORD): Boolean;
procedure Wake;
procedure WakeAll;
end;
← →
Дмитрий Белькевич (2009-08-17 16:26) [42]
> record helper for
Тоже увидел. Вопрос, кстати, образовался. Чем эти хэлперы отличаются от обычного наследования?
← →
Kolan © (2009-08-17 16:29) [43]Ну наследования структур нет. А кроме того, как наследованием добавить методы в середину бибилиотечной иерархии? — Только исправив библиотеку. А бибилиотека может быть и без исходников, кроме того VCL какой-нибудь править — не самое безопасное занятие.
А тут раз:helper for TComponentнаписал и все.
← →
Дмитрий Белькевич (2009-08-17 18:03) [44]Ясно, буду разбираться.
← →
Leonid Troyanovsky © (2009-08-17 21:12) [45]
> Kolan © (17.08.09 16:15) [41]
> А чем принципиально исользование TRTLCriticalSection отличается
> от использования TCriticalSection?
Принципиально, наверное, не отличается.
Как-то обвык без объектов и Enter|Leave :(
--
Regards, LVT.
← →
Vitaliy_____ (2009-08-18 08:29) [46]
> Leonid Troyanovsky ©
Идею твоей программы понял, там кстати целые числа - вполне подошел бы InterlockedExchange, твоя идея для вещественных лучше. Идея плохая :) Где гарантия, что порожденный поток не уснет надолго? (скажем, на час :) ) - тогда "главный" просчитает часть цикла, отпишется через критическую секцию и начнет считать дальше, ведь так? Просчитает ЕЩЕ ОДНУ часть цикла и снова увеличит ct.calcid := ct.calcid + 1;
При мелких вычислениях - очень реальная ситуация. Что при этом будет - а также как у меня где-то проскок через контрольную точку. Хотя, если еще одну контрольную ID-шку добавить, подход сработает. Только по сути это будет спин-блокировка, что крайне не рекомендуется тем же Рихтером.
Поправьте, если не прав...
← →
Leonid Troyanovsky © (2009-08-18 10:12) [47]
> Vitaliy_____ (18.08.09 08:29) [46]
> Идею твоей программы понял, там кстати целые числа - вполне
> подошел бы InterlockedExchange, твоя идея для вещественных
Да хоть для комплексных ;)
> Где гарантия, что порожденный поток не уснет надолго? (скажем,
> на час :) ) -
Эту гарантию должен дать разработчик.
> тогда "главный" просчитает часть цикла, отпишется через
> критическую секцию и начнет считать дальше, ведь так?
Если вторичный поток будет, например, вытеснен не осводив КС,
то первичный, досчитав свой цикл, будет ожидать ее освобождения.
Для гуева потока это может и не очень, но я на гуи и не настаивал.
> Только по сути это будет спин-блокировка, что крайне не
> рекомендуется тем же Рихтером.
Чего-то я такой рекомендации не помню.
Спин-блокировка - самый быстрый механизм синхронизации.
При использовании же КС потоки, все же, попадают в режим ядра.
--
Regards, LVT.
← →
Vitaliy_____ (2009-08-18 12:12) [48]
> Если вторичный поток будет, например, вытеснен не осводив
> КС,
> то первичный, досчитав свой цикл, будет ожидать ее освобождения.
>
> Для гуева потока это может и не очень, но я на гуи и не
> настаивал.
А если все же освободит и уснет в момент проверки while not Application.Terminated do?
Согласен, редкий случай, но возможный. В моем примере тоже по 10-20 итераций делает (то есть по 30 000 образов, в них по 4 барьера) и это * число итераций, а потом вдруг умирает. К счастью, стабильно :)
Нет, должно работать 100%.
А по поводу спин-блокировки, у рихтера это "Худшее что можно сделать"... стр. 195 (215 в моей электронной версии). Сам ее "придумал", потом прочитал, проникся и больше так не делаю :)
Пусть попадают в режим ядра, у меня при большой задаче не такие частые синхронизации, и можно пренебречь 1000 тактов ради того чтобы прога не мешала другим. А вот о "надежности" барьеров - придется самому разбираться, как время найду - хочу добить задачку, может потом статью накатаю :-[c]
← →
Leonid Troyanovsky © (2009-08-18 13:35) [49]
> Vitaliy_____ (18.08.09 12:12) [48]
> А если все же освободит и уснет в момент проверки while
> not Application.Terminated do?
Если вторичный поток вытеснен, то первичный узнает об этом
сравнив ID & calcid, ну и вторую часть ему придется считать самому.
> А по поводу спин-блокировки, у рихтера это "Худшее что можно
> сделать"...
Контекст непонятен. Ладно, посмотрим на досуге.
> Пусть попадают в режим ядра, у меня при большой задаче не
> такие частые синхронизации
Два Event с автосбросом, первичный поток сигналит одним для старта очередной итерации и ждет сигнал готовности от вторичного.
Ну и, конечно, внутри процесса имена объектам не нужны.
--
Regards, LVT.
← →
Vitaliy_____ (2009-08-18 13:51) [50]А если у нас появляется новый проц с 4 ядрами, то 4 event? Нет, не разубедил относительно семафоров.
← →
Leonid Troyanovsky © (2009-08-18 14:45) [51]
> Vitaliy_____ (18.08.09 13:51) [50]
> А если у нас появляется новый проц с 4 ядрами, то 4 event?
Я ж ссылочкой снабжал, насчет эффективной многопоточности.
--
Regards, LVT.
← →
Vitaliy_____ (2009-08-19 06:09) [52]А я даже все статьи прочитал... Это было интересно - но если я не ошибаюсь, для корных процов проблем нет. У меня Core 2 duo e6750 @ 2.66GHz. Да и личный замер, как я писал в [33] более чем убеждает в этом. Хотя у меня в руках теперь хороший тестер, могу сам проверить на других :) Только ждать долго - хорошее разделение нагрузки только на реальной (читать большой) задаче - а ее потом для сравнения надо еще и на однопоточной версии проги прогнать.
← →
Vitaliy_____ (2009-08-26 12:59) [53]Переписал модуль, да обрадуется Leonid Troyanovsky, 2 события для синхронизации достаточно (ну еще счетчик с InterlockedIncrement) :) Пока работает, кому интересно можно потестировать.
Повторюсь, суть этой штуки - барьер с автосбросом - то есть несколько потоков могут "легко и непринужденно" собираться в контрольной точке (вызывая WaitBarrier), при этом когда они дождутся следующий барьер будет автоматически поставлен. Изначально необходимо только проинициализировать число потоков, на которые выставляется барьер.
Если кто протестирует - отпишитесь.
unit BarrierSinchronization;
interface
uses Windows, Utils, SysUtils, SyncObjs;
type TMyBarrierSinchronization=class(TObject)
private
NP:integer; // Число потоков для синхронизации
MBSEvent1,MBSEvent2:THandle; // 2 события для реализации барьера
EvName1,EvName2:String; // Имена событий
state:boolean; // Ключ, с каким событием работаем
Counter: integer; // Внутренний счетчик выполненности заданий
public
procedure Initialize(NumProcesses:integer);
procedure WaitBarrier(const ThreadState:string); overload; // Отладочная версия
procedure WaitBarrier(); overload;
constructor Create;
destructor destroy; override;
end;
var MyBarrierSinchronization:TMyBarrierSinchronization;
resourcestring
WinAPIErrMsg2="Can not create event 1 for synchronization!";
WinAPIErrMsg3="Can not create event 2 for synchronization!";
WinAPIErrMsg4="WaitTimeOut on Event 1!";
WinAPIErrMsg5="WaitTimeOut on Event 2!";
implementation
constructor TMyBarrierSinchronization.Create;
begin
EvName1:=MyUtils.GetUnicalName+"MBSMyEvent";
EvName2:=EvName1+"2";
EvName1:=EvName1+"1";
// Создаем события
MBSEvent1:=CreateEvent(nil,true,false,PChar(EvName1)); // Событие с ручным сбросом, изначально занято
if GetLastError<>0 then raise Exception.Create(WinAPIErrMsg2);
MBSEvent2:=CreateEvent(nil,true,false,PChar(EvName2)); // Событие с ручным сбросом, изначально занято
if GetLastError<>0 then raise Exception.Create(WinAPIErrMsg3);
end;
destructor TMyBarrierSinchronization.destroy;
begin
if MBSEvent1<>0 then
CloseHandle(MBSEvent1);
if MBSEvent2<>0 then
CloseHandle(MBSEvent2);
inherited;
end;
procedure TMyBarrierSinchronization.Initialize(NumProcesses:integer);
begin
NP:=NumProcesses;
Counter:=0;
ResetEvent(MBSEvent1);
ResetEvent(MBSEvent2);
State:=true;
end;
procedure TMyBarrierSinchronization.WaitBarrier(const ThreadState:string);
var key:cardinal;
begin
if state then begin // На нечетных барьерах ждем первое событие, выставляем второе
InterlockedIncrement(Counter);
if Counter=NP then begin
ResetEvent(MBSEvent2);
Counter:=0;
State:=false;
SetEvent(MBSEvent1); // ПОСЛЕДНИМ шагом запустили все потоки
end else begin
repeat
key:=WaitForSingleObject(MBSEvent1,3000);
if key=WAIT_TIMEOUT then begin
MessageBox(0,PChar(WinAPIErrMsg4+#13+ThreadState),PChar(IntToStr(GetCurrentThreadID)),0);
DebugBreak;
end;
until key=WAIT_OBJECT_0;
end;
end else begin // На четных барьерах наоборот
InterlockedIncrement(Counter);
if Counter=NP then begin
ResetEvent(MBSEvent1);
Counter:=0;
State:=true;
SetEvent(MBSEvent2);
end else begin
repeat
key:=WaitForSingleObject(MBSEvent2,3000);
if key=WAIT_TIMEOUT then begin
MessageBox(0,PChar(WinAPIErrMsg5+#13+ThreadState),PChar(IntToStr(GetCurrentThreadID)),0);
DebugBreak;
end;
until key=WAIT_OBJECT_0;
end;
end;
end;
procedure TMyBarrierSinchronization.WaitBarrier();
var key:cardinal;
begin
if state then begin // На нечетных барьерах ждем первое событие, выставляем второе
InterlockedIncrement(Counter);
if Counter=NP then begin
ResetEvent(MBSEvent2);
Counter:=0;
State:=false;
SetEvent(MBSEvent1); // ПОСЛЕДНИМ шагом запустили все потоки
end else begin
key:=WaitForSingleObject(MBSEvent1,INFINITE);
end;
end else begin // На четных барьерах наоборот
InterlockedIncrement(Counter);
if Counter=NP then begin
ResetEvent(MBSEvent1);
Counter:=0;
State:=true;
SetEvent(MBSEvent2);
end else begin
key:=WaitForSingleObject(MBSEvent2,INFINITE);
end;
end;
end;
initialization
MyBarrierSinchronization:=TMyBarrierSinchronization.Create;
end.
// Utils - модуль с утилитами, из него дергается только GetUnicalName - на основе времени создает уникальную текстовую прибавку к имени - можно убрать, т.к. в рамках 1 процесса можно и неименованные события использовать.
← →
Leonid Troyanovsky © (2009-08-26 14:37) [54]
> Vitaliy_____ (26.08.09 12:59) [53]
> if GetLastError<>0 then raise Exception.Create(WinAPIErrMsg2);
Win32Check(MBSEvent1<>0);
MessageBox я б заменил на OutputDebugString, смотреть можно
в дельфийском EventLog.
У WaitForSingleObject есть еще WAIT_FAILED.
> т.к. в рамках 1 процесса можно и неименованные события
А для 2 процессов и InterlockedIncrement не годится.
--
Regards, LVT.
← →
Vitaliy_____ (2009-08-27 09:05) [55]
> У WaitForSingleObject есть еще WAIT_FAILED.
Да. Обработки ошибки ожидания тут нет... Можно добавить.
> А для 2 процессов и InterlockedIncrement не годится.
Да точно, мне в принципе для разных не надо. Хотя чуток напильником поработать и можно будет для разных использовать (взять тот же оптекс у Рихтера за основу).
> MessageBox я б заменил на OutputDebugString
Вот тут не согласен - MessageBox удобен тем, что блокирует поток на время - я вижу на экране несколько сообщений от разных потоков, в нужном давлю ок и через DebugBreak попадаю в отладку именного этого потока (то есть хотя сообщения возникнуть могут не все сразу, я могу подождать и отлаживать именно интересующий меня поток).
← →
Суслик_ (2009-08-28 14:17) [56]Если физический проц один, то только потеряешь производительность, а не получишь ее.
← →
Vitaliy_____ (2009-09-09 13:23) [57]Leonid Troyanovsky, [26]
> Могу заметить, чтобы написать и отладить не очень сложный
> составной объект синхронизации нужна масса времени и терпения.
Кажется придется согласиться :)
Код в [53] все еще не рабочий :) Как я понимаю проблему, у нас "защищен" Counter, но недостаточно защищена переменная state. Редко, но все-таки возникает ситуация "прорывания барьера". Долго не мог понять почему, т.к. возникает крайне редко - тяжело найти. Как раз та самая паршивая ситуация, когда 1 поток "засыпает на долго". Решил потестировать что будет при 4 потоках на двух ядрах, конкуренция возросла, стало появляться чаще. Ох уж ента штука... :)
Попробовал извернуться так:
...
MBSCrSect:TCriticalSection;
...
procedure TMyBarrierSinchronization.WaitBarrier(const ThreadState:string);
var key:cardinal;
WaitintEvent,ResetingEvent:THandle;
begin
MBSCrSect.Enter;
if state then begin // На нечетных барьерах ждем первое событие, выставляем второе
WaitintEvent:=MBSEvent1;
ResetingEvent:=MBSEvent2;
end else begin // На четных барьерах наоборот
WaitintEvent:=MBSEvent2;
ResetingEvent:=MBSEvent1;
end;
inc(Counter);
if Counter=NP then begin
if (ResetEvent(ResetingEvent)=false) then
raise Exception.Create(WinAPIErrMsg6);
Counter:=0;
State:=(state=false);
SetEvent(WaitintEvent); // запустили все остальные потоки
end;
MBSCrSect.Leave; // Все критичные данные в локальных переменных, гонка не возможна.
repeat
key:=WaitForSingleObject(WaitintEvent,7000);
if key=WAIT_TIMEOUT then begin
MessageBox(0,PChar(WinAPIErrMsg4+#13+ThreadState),PChar(IntToStr(GetCurrentThreadID)),0);
DebugBreak;
end;
until key=WAIT_OBJECT_0;
end;
← →
Vitaliy_____ (2009-09-10 05:41) [58]Я кажется наконец понял, что там могло быть:
InterlockedIncrement(Counter);
if Counter=NP then begin
ResetEvent(MBSEvent2);
Counter:=0;
State:=false;
SetEvent(MBSEvent1); // ПОСЛЕДНИМ шагом запустили все потоки
end else begin
repeat
key:=WaitForSingleObject(MBSEvent1,3000);
if key=WAIT_TIMEOUT then begin
MessageBox(0,PChar(WinAPIErrMsg4+#13+ThreadState),PChar(IntToStr(GetCurrentThreadID)),0);
DebugBreak;
end;
until key=WAIT_OBJECT_0;
end;
Похоже, ситуация такая:InterlockedIncrement(Counter);нам гарантирует, что Counter будет "честно" увеличен. А вот дальнейшее сравнениеif Counter=NPнебезопасно. Похоже получалось так: поток увеличивал счетчик и засыпал. После этого последний поток увеличивал счетчик и делал "свои дела", но до Counter:=0 не успевал еще дойти. Просыпался "уснувший" и, опа, он тоже считал себя последним, т.к. Counter=NP все еще истина. Вот и получаем ДВА последних потока. Уже ошибка, хотя событиям все равно сколько через них пройдет (кстати, когда делал на семафорах - там не все равно, потому и вылетало стабильно). Однако может быть так (хотя не спорю, достаточно редко):
У нас два "последних" потока. Один из них запускает все остальные, а второй спит. И если вдруг какой-то поток проснувшись дойдет до след. барьера (т.е. увеличит счетчик) и лишь после этого проснется "лишний последний поток" и выполнит counter:=0 - вот тогда и возникает ошибка. Похоже так. Естественно, вероятность ситуации повышается с увеличением числа потоков.
----------
Чувствую глубокое удовлетворения от познания дебрей ВинАПИ :)
Страницы: 1 2 вся ветка
Текущий архив: 2011.04.17;
Скачать: CL | DM;
Память: 0.61 MB
Время: 0.01 c
