DLL Tparallel.for loop deadock

[Sequitar]

Hallo,
ich möchte gerne eine simple tparallel loop laufen lassen

Beispiel:

Delphi-Quellcode:

procedure test;
var testarray:tarray<string>;
iscontained:boolean;
const A='ABC';//some string;
begin
iscontained:=false;
TParallel.For(0, 4, //kleines array nur zum testen,
      Procedure(I: integer)
      Begin
    // Windows.Beep(3000, 20);
         If Testarray[I].Equals(A)
          Then
        begin  Isscontained := not iscontained;
         break; //kann ich hier so aussteigen?
        end;     

//machwas
        // inc(i);
      End);

In einem demoprojekt (console) läuft der code auch einwandfrei durch. Sobald ich aber das selbe snipplet in eine externe dll auslagere hängt der code ohne ersichtlichen grund (debuggen nicht möglich). GgF IDE Absturz.
Im moment habe ich noch gar keinen worker code in die schleife eingebaut. (sondern NUR die line mit "windows.beep").


PS Der Code ließe sich auch anders gestalten, zb, mit vorheriger aufteilung in fixe listen und dann mehrere threads laufen lassen.
Gerne würde ich mir das sparen, wenn es hier eine einfachere Lösung gäbe.
Merci.

Ich danke für Vorschläge.:)

[jaenicke]

Rufst du CheckSynchronize aus dem Hostprogramm heraus über eine exportierte Funktion in der DLL auf? Nur dann funktioniert die Threadsynchronisation in einer Delphi-DLL normal.

[Sequitar]

Zitat:

Zitat von jaenicke (Beitrag 1495019)

Rufst du CheckSynchronize aus dem Hostprogramm heraus über eine exportierte Funktion in der DLL auf? Nur dann funktioniert die Threadsynchronisation in einer Delphi-DLL normal.

OK Danke!, auf so was wäre ich nie gekommen! - Also die Antwort ist erst mal : nein rufe ich nicht.
Wie genau würde ich dass denn praktisch machen? Hättest du ein kurzes Beispiel?

Geplant war als (kompliziertre Variante) auch Folgendes:

Also ich kommuniziere mit der DLL über ein interface. Innerhalb der interface-Implementierung, zb.

Delphi-Quellcode:

tsomecontainer=class private fworker:tmyworkerthread; {handlearray und waitfor multiple muss noch gebaut werden, sobald der eine hier halt läuft...} end;

habe ich dann mehrere worker threads geplant, die mir eine (bisher lange) berechnung parallelisieren sollten.

Von ausserhalb der dll rufe ich dann nach fertigstellung aller einzelner Threads und der berechnung eigentlich nur das gemeinschaftliche ergebnis ab.


Das wäre mir nur relativ zu viel Aufwand hierfür.

[jaenicke]

Zitat:

Zitat von Sequitar (Beitrag 1495020)

Wie genau würde ich dass denn praktisch machen? Hättest du ein kurzes Beispiel?

Delphi-Quellcode:

unit DllThreadSync;

// Dient zur Nutzung der Threadsynchronisation in einer DLL.
// Nutzung:
// Im OnIdle die exportierte Prozedur ExecuteIdleEvent aufrufen.

interface

uses
  System.Classes;

implementation

procedure ExecuteIdleEvent; stdcall;
begin
  CheckSynchronize;
end;

exports
  ExecuteIdleEvent;

end.

Die Unit bindest du einfach in die DLL ein und rufst im OnIdle der Hostanwendung die exportierte Prozedur ExecuteIdleEvent auf.

[Sequitar]

Super!!:-D Vielen Dank für den Tip. Das funktioniert einwandfrei.
Sorry, dass ich jetzt erst antworte. Aber ich kam bisher noch nicht dazu es auszuprobieren.

[himitsu]

Die andere Alternative wäre, die EXE und DLL mit Laufzeitpackages zu kompilieren.

Gut, "handlicher" wäre es, wenn es direkt von Embarcadero eine Unit gäbe, um derartige Verknuppelungen "automatisch" in die DLL einzubinden.

[Sequitar]

Das mache ich sowieso schon - sonst komme ich ja nicht an die gemeinsamen interfaces (OK ich glaube Tvirtualinferfaces, aber BPL und eine gemeinsame intf-declaration war an der stelle das komfortableste). DLL wird halt dynamisch nachgeladen, aber das sollte keinen Unterschied hierfür machen.

[Sequitar]

Zitat:

Zitat von Sequitar (Beitrag 1495403)

Das mache ich sowieso schon - sonst komme ich ja nicht an die gemeinsamen interfaces (OK ich glaube Tvirtualinferfaces, aber BPL und eine gemeinsame intf-declaration war an der stelle das komfortableste). DLL wird halt dynamisch nachgeladen, aber das sollte keinen Unterschied hierfür machen.

Also egal, was ich mache (hab die selbe unit jetzt in einer eigenen exe laufen (ohne BPL / DLLs), IDE ist frisch installiert, icnl upd. 2):

Mein originaler Code läuft einwandfrei. Sobald ich die Multithreaded version laufen lasse hab ich irgendwie eine endlos-schleife wo keine sein sollte.
Da ich mich erst seit kurzem mit MT intensiver beschäftige vermute ich einen unentdeckten deadlock. Es macht es allerdings nicht einfacher, wenn die IDE beim Debug anzeigt, dass ein ein essentieller Wert nicht mehr verändert wird(obwohl ansonsten exakt gleicher code??. Naja das war zumndest das was ich erreichen wollte).

Ich behaupte jetzt mal ,dass es gar nicht an der synchornizsations-geschichte liegt, sondern ich hier einfach mist gebaut hab. War mal ein erster test MT irgendwo sinnvll einzubauen. Da hab ich einen alten Integer Faktorization abschnitt genommen. (Ja es gibt bessere varianten, aber darum solls bitte nicht gehen )

Ich würde einen von euch mal bitten, sich das vlt mal anzusehen. Sources / libs anbei

Vielen Dank

[TiGü]

Ne, so geht das nicht!
Das ist so nicht aus dem Hut ohne große Anpassung lauffähig.
Dein Vorname Nachname steht als "Output Path" für Win32 Debug drin.
Dann gibt es Heckmeck mit den Laufzeitpackages und wenn man das aus der Projektdatei entfernt hat, dann will er die Units Shared.Globals, Unittests, Utils.Messagelog, Objects.Factory usw. einbinden, die aber nicht mitkommen.

Versuch bitte nochmal dein Problem zu verkleinern.

[Sequitar]

Zitat:

Zitat von TiGü (Beitrag 1495425)

Ne, so geht das nicht!
Das ist so nicht aus dem Hut ohne große Anpassung lauffähig.
Dein Vorname Nachname steht als als Output Path für Win32 Debug drin.
Dann gibt es Heckmeck mit den Laufzeitpackages und wenn man das aus der Projektdatei entfernt hat, dann will er die Units Shared.Globals, Unittests, Utils.Messagelog, Objects.Factory usw. einbinden, die aber nicht mitkommen.

Versuch bitte nochmal dein Problem zu verkleinern.

Guter punkt. ichhab die paths noch nicht angepasst. ich werde heute nachmittag eine mvp ohne packages hochladen. dank für den hinweis.:-D

[Sequitar]

Zitat:

Zitat von Sequitar (Beitrag 1495434)

Zitat:

Zitat von TiGü (Beitrag 1495425)

Ne, so geht das nicht!
Das ist so nicht aus dem Hut ohne große Anpassung lauffähig.
Dein Vorname Nachname steht als als Output Path für Win32 Debug drin.
Dann gibt es Heckmeck mit den Laufzeitpackages und wenn man das aus der Projektdatei entfernt hat, dann will er die Units Shared.Globals, Unittests, Utils.Messagelog, Objects.Factory usw. einbinden, die aber nicht mitkommen.

Versuch bitte nochmal dein Problem zu verkleinern.

Guter punkt. ichhab die paths noch nicht angepasst. ich werde heute nachmittag eine mvp ohne packages hochladen. dank für den hinweis.:-D

Das gestaltet sich - wg veränderter initialisierungsreihenfolge- etwas schwierig, alles in eine einzelne exe zu packen. Da ich im moment relativ wenig zeit hab, brauch ich damit wohl noch 1,2 tage, wenn es anders gar nicht geht.
Trotzdem erst mal danke für die hilfe
seq

[Sequitar]

Zitat:

Zitat von Sequitar (Beitrag 1495450)

Zitat:

Zitat von Sequitar (Beitrag 1495434)

Zitat:

Zitat von TiGü (Beitrag 1495425)

Ne, so geht das nicht!
Das ist so nicht aus dem Hut ohne große Anpassung lauffähig.
Dein Vorname Nachname steht als als Output Path für Win32 Debug drin.
Dann gibt es Heckmeck mit den Laufzeitpackages und wenn man das aus der Projektdatei entfernt hat, dann will er die Units Shared.Globals, Unittests, Utils.Messagelog, Objects.Factory usw. einbinden, die aber nicht mitkommen.

Versuch bitte nochmal dein Problem zu verkleinern.

Guter punkt. ichhab die paths noch nicht angepasst. ich werde heute nachmittag eine mvp ohne packages hochladen. dank für den hinweis.:-D

Das gestaltet sich - wg veränderter initialisierungsreihenfolge- etwas schwierig, alles in eine einzelne exe zu packen. Da ich im moment relativ wenig zeit hab, brauch ich damit wohl noch 1,2 tage, wenn es anders gar nicht geht.
Trotzdem erst mal danke für die hilfe
seq

Hat etwas gedauert. Entschuldigung.
Ich hoffe ich hab jetzt die entsprechenden paths alle abgeändert.

Dazu hab ich ein minimum-core package zusammengestellt, das die notwendigen interfaces und globale pfade etc enthält. Das hat jetzt aber keine debuginfos mehr drin.
Die ResourcenDLL ist noch nicht compiliert, hierzu liegen die resources bei.

!!FactorizeMT_minimal.ini: Hier müssen die wichtigen Pfade (your user name\myprojects\plugins etc..) noch angepasst werden
(danke für den tip übrigens, ich denke ich hab sonst alle rausgelöscht).
Es gibt auch noch die möglichkeit, sich einen anderen logger (für eine ausgabedatei, standardmäßg über die console) zu registrieren.



Wg.der resources ist das Archiv jetzt übergroß und wird nicht hochladen:
https://www.dropbox.com/s/oqsj97uln4...izeMT_test.zip

[Sequitar]

Ich muss mich heute noch mal zurückmelden:

Wenn ich eine einfache for loop teste:

Delphi-Quellcode:

 
 CheckSynchronize;
 Tparallel.For(1, 10,
    Procedure(I: Integer)
    Begin
// CheckSynchronize;//?? macht keinen Unterschied
      Writeln(I);
    End);

, dann komme ich beim Debuggen
in Unit <system.threading>, l. 1583

Delphi-Quellcode:

class function TParallel.&For(ALowInclusive, AHighInclusive: Integer; const AIteratorEvent: TProc<Integer>): TLoopResult;
begin
  Result := ForWorker(..)
end;

Dann kann ich nach l. 3100 und springen:

Delphi-Quellcode:

class function TThreadPool.GetCurrentThreadPool: TThreadPool;
..

Hier wird dann auch eine entsprechende instanz zurückgegeben

allerdings hängt die Ausführung in der class procedure

Delphi-Quellcode:

class function TParallel.ForWorker(..)
//..

//l. 1414:
RootTask.Start.Wait;

//also scheint der "roottask" thread in dem fall nicht gestartet, denn er wartet an der Stelle vergeblich
//nach erfolgter Ausführung der function ttask.start:itask


Macht das irgendeinen Sinn? Ich meine, ich kann auch einen ganz normalen Thread laufen lassen (so hab ich z.b. einen "working indicator" im Hintergrund (ne Art "ladebalken, der mir einfach eine bestimmte Zeichenfolge -/-\...) ausgibt. Der läuft auch einwandfrei, (ist natürlich aber auch von nichts externem abhängig).

BTW, konnte das Problem jemand reproduzieren anhand der Anhänge?


Vielen Dank

[Sequitar]

Also ganz ehrlich, das kann doch nicht sein?! Irgendwas läuft da grundlegend falsch.
Ich dachte, ok paralell geht nicht, steige ich - mit mehraufwand - auf normale threads um.
Es stellt sich raus, ...das geht genauso wenig.

Nehmen wir folgende minimalklasse

Delphi-Quellcode:

type
  tmythread = class(Tthread)
    procedure Execute; override;
  end;

Procedure tmythread.Execute;
Begin
  While Not Terminated Do
  Begin
    Sleep(1000);
    Writeln(Timetostr(Now));
  End;
End;

und packen sie in eine standalone exe. ...

Delphi-Quellcode:

 with tmythread.Create(true) do
  begin
    start;
    waitfor;
    free;
    end; //unbeachtet der endlosschleife hier

gibt das ganz normal jede sekunde eine zeit aus. Soweit so gut,

packe ich DENSELBEN code in eine dynamisch geladene dll

..NIX

Der Thread (zum testen innerhalb der dll "gestartet") gibt nix aus. Es zeigt sich dass, beim Aufruf der Methode "start"
a) irgendein Tobject.create aufgerufen wird (ok kann ja im hintergrund sein)
b) direkt dabei eine access violation auftritt bei

Delphi-Quellcode:

function _ClassCreate(InstanceOrVMT: Pointer; Alloc: ShortInt): Pointer;
//..
  CALL    DWORD PTR [EAX] + VMTOFFSET TObject.NewInstance

//..
end;

Im Call-Stack listet er dann noch system.classes.objecttexttoresources() auf, das ist dann aber so tief in den internals der rtl. Ich dachte nicht dass mich so ein code überhaupt tangiert..?


Das "onidle" wie ganz zu beginn mal angemerkt, wurde auch hier exportiert. Aber es kann doch nicht sein,ddass ich *keinen* einzigen Thread in der dll laufen lassen kann (außer app main thread)?

Ich bin echt ratlos, liebe leute.
Danke schon mal für euer feedback.

[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

Delphi-Quellcode:

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?