что есть рантайм? менеджер памяти? менеджер памяти у DLL свой, у приложения - свой а я ещё хочу из той DLL - звать другую DLL ) вообще на Си/++ писанную, и у неё тоже будет внутри что-то своё, свой менеджер памяти
Рантайм это грубо говоря system в паскале. Разный менеджер памяти приведет к глюкам если выделить память в одном, а освободить в другом. Writeln должен быть потокобезопасным но если рантайм разный, то могут быть проблемы
Аха, память у меня изолирована между DLL и приложением, у каждого своя, обмена нету
Память не изолирована но RTL разный
ну и пусть, RTL это же просто код, какие могут быть проблемы если у него свои данные и кроме него никто другой туда не полезет?
Кстати writeln не потокобезопасный.
Да, я тока что убедился в этом )
Матюгаться охота, других слов нет.
приложение падает, или просто возникает путаница в выводе сообщений?
Путаница и падение с ЕГГОГ 201 (но я уже не за компом, вроде 201)
Хотя, стоит отметить, что я писал в файл, а не в консоль
В консоль - вывод через WriteLn из множества потоков работает нормально (FPC 3.3.1, Windows 11) В файл - вывод через WriteLn из множества потоков работает нормально (FPC 3.3.1, Windows 11), только если синхронизировать вывод
fpc 3.2.2, windows 10 WriteLn не работает нормально
program project1; uses Classes, SysUtils; type TMyThread = class (TThread) oftype: byte; procedure Execute; override; end; var i: Integer; threads_arr: array [0..2] of TMyThread; //cs: TRTLCriticalSection; //f: TextFile; procedure WriteRnd(oftype: byte); begin //EnterCriticalSection(cs); //WriteLn(f, 'type: ', oftype, ' end;'); //LeaveCriticalSection(cs); WriteLn('type: ', oftype, ' end;'); end; procedure TMyThread.Execute; var t1: TDateTime; begin t1:=Now; while (Now-t1)*MSecsPerDay<2000 do WriteRnd(oftype); end; begin //AssignFile(f, 'threads_test.txt'); //Rewrite(f); //InitCriticalSection(cs); for i:=0 to 2 do begin threads_arr[i]:=TMyThread.Create(True); threads_arr[i].oftype:=i; end; for i:=0 to 2 do threads_arr[i].Start; for i:=0 to 2 do threads_arr[i].WaitFor; for i:=0 to 2 do threads_arr[i].Free; //DoneCriticalSection(cs); //Close(f); ReadLn; end. Я так тестировал
Проверил и в 3,2,2 - тоже работает
Так много поточную запись в файл в любом случае надо синхронизировать. Не важно writeln или что
ну в общем говоря - на уровне API Windows - нет поддержки многопоточного вывода в файл, по крайней мере в функции WriteFile
Ну теперь интересно - работает? Нашлась проблема? Или реально под Win10 так работает - отлично от Win11?
Пример не приведу, при выводе из нескольких потоков без синхронизации периодически рвёт строку пополам. Но это ожидаемое поведение.
А, ну хотя может, я то так... наколеночно протестировал
Если хочется прямо правильно и не думать сильно - бери стандартную модельку producer-consumer, там очередь.
Обсуждают сегодня