Много процессов

← →
Andrew2 (2004-06-18 12:28) [0]

В DLL находится модуль, производящий вычисления, вот часть кода:

(* TMyParam is a record *)
procedure Calc( var Param: TMyParam );
var Calc : TCalc;
begin
Calc := TCalc.Create( Param );
Calc.Execute;
Calc.Free;
end;

function LibraryEvent( Val : Integer ):boolean;
begin
IsMultiThread := true;
result := TRUE;
end;

exports Calc name "Calc";

begin
if DllProc <> nil then
DllProc := @LibraryEvent;
end.

В моем приложении несколько потоков. В каждом потоке эта DLL динамически подгружается через LoadLibrary и дергается процедура Calc из DLL.

Когда оба потока начинают интенсивно вызывать этот метод, приложение беззвучно падает. Я выяснил, что при этом вычисления выполняются в одном экземпляре класса TCalc для обоих потоков, а не в отдельном для каждого потока.

Подскажите, что я неправильно делаю?

Спасибо.

← →
TUser © (2004-06-18 12:37) [1]

Надо в dll создавать отдельный поток для каждого вычисления.
TCalc д.б. наследником от TThread. Если это уже так, то никогда не вызывай его Execut"ом, надо использовать метод Resume.

← →
Andrew2 (2004-06-18 12:41) [2]

Сейчас это не так.

А почему в моем случае TCalc не создается для каждого потока свой, изолированный?

← →
TUser © (2004-06-18 12:55) [3]

Ну, код-то у тебя один и тот же. dll в памяти один раз сидит. Лучше потоками.

PS. Дело личное, конечно, но на мой взгляд это плохо, что слово Calc 2 раза используется и с разным смыслом.

← →
Andrew2 (2004-06-18 13:14) [4]

В живом коде названия разные, это здесь в примере так неудачно названо.

Не хочется создавать отдельный поток для каждого вычисления, тяжело это для машины.

Хочу понять: подход, который применял я, в принципе неверен и так нельзя делать для изоляции вычислений в разных потоках?

← →
Тимохов © (2004-06-18 13:25) [5]

что такое tcalc?

← →
Andrew2 (2004-06-18 13:50) [6]

Это класс, который выполняет вычисления над данными, переданными ему в конструкторе. Он самодостаточен и не может влиять на такое поведение DLL и приложения.
Виноват кто-то другой.

← →
han_malign © (2004-06-18 13:56) [7]

function LibraryEvent( Val : Integer ):boolean;
begin
IsMultiThread := true;
result := TRUE;
end;

exports Calc name "Calc";

begin
if DllProc <> nil then
DllProc := @LibraryEvent;
end.
- нормальные люди делают так
exports Calc name "Calc"; begin IsMultiThread := true; end.

← →
panov © (2004-06-18 13:59) [8]

>Andrew2 (18.06.04 13:50) [6]

Это класс, который выполняет вычисления над данными, переданными ему в конструкторе. Он самодостаточен и не может влиять на такое поведение DLL и приложения.
Виноват кто-то другой.

Возможно, но уже много раз говорили про телепатов.

Надо видеть вычисления в библиотеке, описания функций, вызовы из основного модуля, чтобы хоть приблизительно видеть, правильно или нет хотя бы вызовы идут.

← →
panov © (2004-06-18 14:02) [9]

Кроме этого, DLLProc - функция, которая имеет определненое назначение и параметры:

procedure DllMain(fdwReason:DWORD);
begin
case fdwReason of
DLL_THREAD_ATTACH: ;
DLL_THREAD_DETACH: ;
DLL_PROCESS_ATTACH:
begin
end;
DLL_PROCESS_DETACH:
begin
end;
end;
end;

exports
pInc,
pDec,
GetValue,
SetValue,
mv,
MemComp,
CreateList,
GetMsg,
AddMsg,
DelMsg,
DelAllMsg,
GetRootMsg,
GetCountMsg,
GetNextAddrMsg,
GetPrevAddrMsg,
GetLenMsg,
FFirst,
FNext,
FFClose,
FFileListA,
AddBackSlash,
DelBackSlash,
CreateDirPath,
ErrMessage,
TickCount,
DeltaTickToSeconds,
PadL,
PadR,
PadC,
B8toB7,
B7toB8,
c2c,
FilePath,
FileName,
ReplFileExt,
CreateLog,
WriteLog,
CloseLog,

CreateBitsArray,
DeleteBitsArray,
SetLenBitsArray,
GetLenBitsArray,
GetByteBitsArray,
GetIntBitsArray,
GetInt64BitsArray,
isBitBitsArray,
GetBitBitsArray,
SetBitBitsArray,
GetOrderBitsArray,
SetOrderBitsArray,
GetFirstIndexBitsArray,
SetFirstIndexBitsArray,
GetStrBitsArray,
SetStrBitsArray,
SetByteBitsArray,
SetIntBitsArray,
SetInt64BitsArray,
SetMemBitsArray,

ExecCmd,
SearchSubStr,
BinToInt,
IntToBin,
CreateTimerLight,
TerminateTimerLight,
SuspendTimerLight,
ResumeTimerLight,
SetCallBackProcTimerLight,
isRunning,
IniName,
GetParmStr,
GetParmInt,
GetParmStruct,
WriteParmStr,
WriteParmInt,
WriteParmStruct;

begin
DllProc:=@DllMain;
DllMain(DLL_PROCESS_ATTACH);
end.

← →
han_malign © (2004-06-18 14:02) [10]

>приложение беззвучно падает
- а это как раз означает, что твои манипуляции с IsMultiThread - ни к чему не привели.
Причем падает, скорее всего, не на выполнении, а на TCalc.Create( Param ), потому что IsMultiThread отвечает за критическую секцию при управлении динамической памятью...

← →
Andrew2 (2004-06-18 14:16) [11]

>- нормальные люди делают так
Спасибо, это я попробую.

>Надо видеть вычисления в библиотеке,
К сожалению, TCalc мне дается в готовом виде.

>Причем падает, скорее всего, не на выполнении, а на TCalc.Create( Param ), потому что IsMultiThread отвечает за критическую секцию при управлении динамической памятью...
Только происходит это не сразу и не каждый раз.

Может быть, криминал в том, что LoadLibrary делается из каждого потока, а не из основного потока приложения?

← →
panov © (2004-06-18 14:19) [12]

>Andrew2 (18.06.04 14:16) [11]

и DLLProc у тебя не вызывается...

← →
Andrew2 (2004-06-18 14:34) [13]

Как я понимаю, она здесь, как заглушка. В ней нечего делать.

а
IsMultiThread := true;
это что и где используется?

← →
Andrew2 (2004-06-18 16:35) [15]

Да, вообще-то, нигде. Прочитал чей-то совет. Так понимаю, что это глобальная переменная. Но ее удаление на поведение DLL не влияет

IsMultiThread := true;
это что и где используется?

В менеджере памяти. Есть IsMultiThread установлена в True, то входит в критическую секцию при операциях с памятью.

Падает только в нескольких потоках или при одном тоже?

← →
Andrew2 (2004-06-18 17:04) [18]

При одном живет железно и неограничено долго. Если вставить сброс лога в файл, видно: каким-то образом один TCalc ввыполняет расчет для обоих потоков, правда, не каждый раз. После нескольких таких совмещений приложение умирает без каких-либо сообщений. Хотя все, что можно, упаковано в try .. except.

Много процессов - одна DLL Найти похожие ветки