also folgendes problem:

ich will was mit threads machen. klappt auch wunderbar, ich rufe in der "execute"-methode "dosomething" auf.

wenn ich "dosomething" mit "Synchronize(dosomething)" aufrufe klappt es bis zum letzten befehl in "dosomething" (das showmessage das ich da platziert habe, kommt noch). dann kommt allerdings eine AccessViolation (siehe bild 1, absoult nichtssagen). das showmessage, dass in der "execute"-methode dann folgt wird logischerweiße nicht mehr ausgeführt.

lasse ich das "Synchronize" weg, dann schmiert er schon mitten in der "dosomething"-methode ab. (siehe bild 2 - ich hab allerdings weit und breit keine leinwand und auch kein bild, nur filestreams)

--> warum krepiert mein thread beim sich beenden?


edit: die beiden (nichtssagenden) bilder hochgeladen
edit2&3: richtige bilder hochgeladen

ich hab jetzt mal ein dynamisches array in der funktion (dosomething) durch ein festes array ersetzt --> es klappt (noch nicht ganz, aber ich bekomme zumindest keine accessviolation mehr)

ich melde mich nochmal falls es ganz funktioniert, oder ich nicht mehr weiterkomm. hat einer ne ahnung woran das liegen könnte? und nein, es war kein indexoutofbounds!!!

nailor

Hi,

Die Meldung "Leinwand/Bild erlaubt kein Zeichnen" bedeutet, dass du im Thread irgendeine Zeichenoperation (Invalidate oder ähnliches) auslöst, während die Zeichenfläche durch den Hauptthread blockiert ist, oder umgekehrt. Auf die GUI solltest du nicht gleichzeitig aus 2 Threads zugreifen. Die VCL ist da nicht unbedingt threadsicher.

Wenn du im Execute vom Thread nur eine Funktion mit Syncronize aufrufst, dann verhält sich das ganze eigentlich so, als ob nicht mit Threads arbeitest.

Versuchs mal mit MessageBox anstatt mit mit ShowMessage. Wie bereits erwähnt ist die VCL nicht wirklich threadsicher.

grüße, daniel

sehe ich das richtig: synchronize sollte man nicht nehmen, wenn nicht undedingt nötig, da es das thread-system unterwandert?
der zweite fehler kam, weil ich zweimal auf einmal auf die gui zugegriffen habe?

Zitat von nailor:

sehe ich das richtig: synchronize sollte man nicht nehmen, wenn nicht undedingt nötig, da es das thread-system unterwandert?

Ganz genau. Synchronize ist für die Kommunikation des Threads mit der Außenwelt zuständig.
Wie der Name schon sagt wird der Thread dabei mit dem Hauptthread synchronisiert, also muss er warten.

Zitat von nailor:

der zweite fehler kam, weil ich zweimal auf einmal auf die gui zugegriffen habe?

Höchstwahrscheinlich. Ein Thread hat einen Canvas gelockt und ein anderer wollte darauf zeichnen.

gut hab es jetzt am laufen *froi*

jetzt allerdings nochmal zum "kommunizieren mit der außenwelt": angenommen, mein thread soll regelmäßig irgendwelche lebenszeichen und fortschrittsangaben nach außen funken. ist es dann am geschicktesten, die rechen-methode normal (ohne synchro) laufen zu lassen, und von zeit zu zeit über "synchronize(IchLebeNoch(UndDasIstMeinFortschritt) )" dem hauptteil meines programmes bescheidzusagen, wie es um den thread steht?
und wie kann ich im hauptprogramm rausfinden, ob der thread noch am laufen its, oder nicht. irgendwie hab ich keine möglichkeit gefunden, außer dass der thread selbst vor dem beenden bescheid gibt, aber dann ist er ja noch nicht ganz fertig...

Zitat von nailor:

jetzt allerdings nochmal zum "kommunizieren mit der außenwelt": angenommen, mein thread soll regelmäßig irgendwelche lebenszeichen und fortschrittsangaben nach außen funken. ist es dann am geschicktesten, die rechen-methode normal (ohne synchro) laufen zu lassen, und von zeit zu zeit über "synchronize(IchLebeNoch(UndDasIstMeinFortschritt) )" dem hauptteil meines programmes bescheidzusagen, wie es um den thread steht?
und wie kann ich im hauptprogramm rausfinden, ob der thread noch am laufen its, oder nicht. irgendwie hab ich keine möglichkeit gefunden, außer dass der thread selbst vor dem beenden bescheid gibt, aber dann ist er ja noch nicht ganz fertig...

Am performantesten wird es sein, die Statusinformationen in eine Variable zu schreiben (dessen Adresse man zum Beispiel dem Thread als Property mitgeben kann oder die statisch sein könnte falls nur ein Thread läuft...).
Dann wird der Thread nur solange aufgehalten, wie die Variable durch das Auslesen des Hautpthreads blockiert ist (dass die Variable/Struktur zum Lesen/Schreiben gelockt wird, setze ich einfach mal als selbstverständlich voraus ).


Gruss Nico

meine idee -> thread ruft funktion im hauptprogramm auf und übergibt parameter

deine idee -> hauptprogramm liest variable des threads aus


neue idee von mir -> thread schreibt varialbe im hauptprogramm


------

wie ist es am geschicktesten zu regeln? und das zweite ist: wie kann ich am sinnvollsten rausfinden, ob mein thread noch am laufen ist?

idee -> vor dem schließen noch eine "ich schließe jetzt" statusmeldung absetzen

andere ideen -> ?

Zitat von nailor:

deine idee -> hauptprogramm liest variable des threads aus

Eher: Hauptprogramm liesst Variable, welche vom Thread geschrieben wird.

Letztendlich läuft alles darauf hinaus, die Anzeige von der Funktionalität zu trennen.

Zur letzten Frage: Es gibt eine Eigenschaft von TThread, die vorgibt, ob das Thread-Objekt beim Beenden automatisch freigeben werden soll (Name hab ich vergessen). Wenn das deaktiviert wurde, kannst Du jederzeit Abfragen ob der Thread bereits fertig ist (sonst würde es eine Excepton, beim Versuch auf das freigegebene Objekt zuzugreifen, geben...).


Gruss Nico

ps: Wenn es sich bei der Status-Variablen um einen Integer handelt (Prozent, oder was auch immer), dann reichen die InterlockedXxx-Funktionen aus und man muss nicht noch ein Locking-Objekt für die Status-Struktur einführen.

trennen (anzeige/rechnen): ok, ist bei mir oft eh so eingerichtet

über ne exception zu testen, ob was noch da ist... na ja. dann nehm ich lieber die version, die testet, ob der fortschritt komplett durchgelaufen ist

das mit interlocked schau ich mir mal an, hört sich gut an. von einem locking objekt hab ich keine ahnung. vielleicht lern ichs ja jetzt

nailor