DLL Tparallel.for loop deadock

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

[Sequitar]

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

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

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

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