DLL Tparallel.for loop deadock

[Sequitar]

Ich habe heute mal etwas Zeit gefunden, mich noch einmal mit dem Problem zu beschäftigen. Es ist mir tatsächlich gelungen den code auch innerhalb der dll laufen zu lassen (zum test einfach mal eine simple procedure exportiert:

Delphi-Quellcode:

procedure paral_for;
var
  l: Tlist<Boolean>;
  pc: Iprimecheck;
const
  N = 5000;
var
  Indicator: Tindicatorthread;
  Pool: TThreadPool;
begin
  l := Tlist<Boolean>.Create;
  pc := Tfactory.New<Iprimecheck>;
  Indicator := Tindicatorthread.Create(False);
  Indicator.FreeOnTerminate := True;
  Logger.Add('checking the first ' + inttostr(N) + ' primes.Multithreaded.');
  try
    Pool := TThreadPool.Create;
    Pool.SetMaxWorkerThreads(3);
    Pool.SetMinWorkerThreads(3);
    TParallel.For(0, N,
      procedure(I: Integer)
      begin
        l.Add(pc.Checkprime(inttostr(I)));
      end, Pool);
  finally
    Pool.Free;
    Indicator.Terminate;
    for var B in l do
      Writeln(B);
    l.Free;
  end;
end;


//..
 paral_for name 'checkprime_paralFor',

In der main app lasse ich die dann laufen, wie gewünscht:

Delphi-Quellcode:

//loadlibrary(..);
 Tester.Test(
    procedure
    begin
      @paral_for_external := getprocaddress(module,
        Pchar('checkprime_paralFor'));
      if Assigned(@paral_for_external) then
        paral_for_external;
    end, 'external Parallel for loop');
//..
//freelibrary(..);

Zwei (prominente) dinge habe ich am setup geändert:
-Jetzt arbeite ich an einem anderen PC - Gleiche Delphi-Version 10.4 comm.
- KEINE nutzung von Sharemem.pas (dem Memorymanager). Die war irgendwie in der DLL aktiv, komischerweise nicht aber in der exe.

Ich würde mal auf die Kausalität mit letzterem tippen. Kann das sein? Es war ja der Fall, dass es mir die IDE ja nicht mal erlaubt hat, in den Funktionskörper der Tparalell.for ().. zu springen, sondern sie hat an der Stelle immer direkt gehangen.

Lange rede, kurzer Sinn:
Ich denke ich habe das / ein kritisches Problem gefunden und beheben können. Zumindest in einem Testcase macht der code-Abschnitt jetzt was er soll. Ich bin gespannt, wie es aussieht, wenn ich das auf den originalcode anwende.


BTW: *darf* man ungeschützt innerhalb der paralel-loop auf eine gemeinsame liste zugreifen (sprich brauche ich hier eine CS oder macht der das in dem Fall selber?). Im allgemeinen würde ich das ja nicht so machen.

[Sequitar]

OK, es läuft. Jetzt bleibt die Frage, wieso ist es als Multithreaded-Version *signifikant* langsamer?
Um die tparallel.&for() loop nutzen zu können, muss ich ja einen min, und einen max wert angeben, um terminieren zu können. Soweit so klar. Also hol ich mir einen array[min..max], fülle den auf (das muss im moment noch linear erfolgen, schien mir ein bottleneck zu sein, daher hab ich den teil jetzt auf pointers umgestellt (anstatt
for i:=low to high do ar[i]:=//... jetzt

Delphi-Quellcode:

filler:=@ar[low];
stop:=@ar[high];
while filler<>stop do
begin
filler^:=//..
inc(filler)
end;
//last item
filler^:=//..

und lasse per parallel loop auf teilbarkeit (relativ einfach)/ primality (sehr rechenintensiv. hieran hängts's wohl, dass es trotzdem nicht schneller ist.) testen. Hier hatte ich aufgrund der parallelen Bearbeitung (vorallokation eines Threadpools, getestet mit unterschielicher Größe von 2,8,16 Threads) der intensiven schritte auf einen Vorsprung gegenüber linearem testen gehofft. Das gegenteil scheint, ceteris paribus, der fall.
Am Befüllen scheint es nach entsprechender Testung nicht zu liegen. Hier habe ich abseits mal einen vergleich laufen lassen, und kaum unterschiede feststellen können
(WO)Mache ich einen Denkfehler?