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 von 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.

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. 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 von Sequitar:

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!! 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 von 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.

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 von TiGü:

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.