Das deutsche QBasic- und FreeBASIC-Forum

[creepi]

Hi,
ich bin ein wenig am verzweifeln. Hab verschiedene möglichkeiten durch und weiß nicht mehr weiter : /
Vielleicht könnt ihr ja helfen?

Damit das hauptprogramm nicht kurz hängt wollt ich eine verarbeitung in ein thread packen so das es im hintergrund durch gegangen wird. Anfangs gab es hin und wieder crashs den hab ich nun im griff bekommen, lag beim hauptprogramm am screenlock / cls das findet der thread wohl nicht toll.
Prüfe ob screenlock gerade aktiv ist dann wird die aufgabe im thread noch nicht ausgeführt usw.
Im thread selbst gibt es keine anzeige ausgabe, kein draw oder print.
Den thread hab ich nun auch per screenset auf eine andere ebene gestellt während 0 der aktive bildschirm bleibt. Also thread hab ich auf screenset 3,0 gesetzt.

Wie es nun zu dem flackern kommt ist mir ein rätsel. Es taucht nicht direkt auf, scheint eher zufällig zu sein. Mit der eigtl. berechnung im thread scheint es nichts zu tun zu haben. Denn auch wenn diese erledigt ist flackert es fröhlich weiter.

Das hauptprogramm ist natürlich durch screenlock & screenunlock eigtl. gegen das flackern ausgelegt. Keine grafikausgabe ohne screenlock.
Wenn ich den thread nicht starte, gibt es auch kein flackern.

Kennt jemand das problem??
Hab ein kurzen clip erstellt: https://www.youtube.com/watch?v=PAqT2umLaM0

Wäre schön wenn jemand das problem kennt und ggf. eine lösung weiß.
Nutze die aktuellste fb version.

Ich bedanke mich schon einmal rechtherzlich im voraus.


*mitkopfauftischknall*, edit: zu früh gefreud crashen tu es auch noch... liegt es an mir oder ist die sache mit dem thread recht instabil :/
Achte bei den shared variablen auch darauf das keine genutzt wird ohne das vorher mutelock / muteunlock.... is doch zum verrückt werden
...wie die nadel im heuhaufen...

[grindstone]

Hallo creepi!

Die Grafikbefehle von FB sind nicht threadsicher. D.h., daß du in einem mit "ScreenRes" angelegten Fenster auch alle Befehle, die irgendwie auf den Grafikspeicher zugreifen, wie "Print", "Put", "Locate", "Line" usw. mit einem Mutex absichern musst (siehe auch http://forum.qbasic.at/viewtopic.php?t=8315&start=20&postdays=0&postorder=asc&highlight=).

Das kann je nach Anwendung ziemlich umständlich werden.

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[MOD]

Hinweis: Ab der nächsten FB Version (0.91) sind alle Grafikbefehle threadsafe.

[grindstone]

Das ist ja mal eine gute Nachricht

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[creepi]

aber nicht für mich
So hät ich zumindest jetzt einen anhaltspunkt gehabt
trotzdem danke

stop, moment, nächsten?
stimmt aktuell ist ja die 0.90.1 und nicht 0.91 AAH!
ok, frage am rande: gilt put unsicherheit innerhalb des threads?
Weil im thread selber nutz ich put nicht sondern im hauptprogramm, wäre das ein faktor?

@nemored (unter mir) gleiches timing gehabt

[nemored]

Hast du denn 0.91? Offiziell heraus ist erst 0.90.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[creepi]

mmmmh, unterm strich könnt ich jetzt zumindest sagen es liegt nicht an mir sondern an fb, kommt auch nicht gerade häufig vor ; )

Das der thread auf screenlock / cls allergisch reagierte fand ich ja schon raus als ich ein kleines test-prog dann schrieb. Das nun aber auch grafikbefehle schuld sind erklärt zumindest warum immer noch ab und an ein crash folgt obwohl screenlock gesichert ist. Heist es wohl notfalls warten auf die neue version. Mal schauen... nu brauch ich mir nicht mehr soooo den kopf zerbrechen wo der fehler liegt. Danke

[MOD]

Es ist eigentlich ganz einfach: andere Threads machen die Berechnungen, der Hauptthread zeichnet. So ist das zu machen, so macht das keine Probleme.

[St_W]

Du solltest generell nur an einer Stelle im Programm zeichnen. Also ein Screenlock, dann alles zeichnen und schlussendlich wieder ein Screenunlock.

Wenn du mehrmals Screenlock/-unlock verwendest (egal ob im selben Thread oder in einem anderen) hilft das ja dann nicht gegen flackern zwischen den beiden Zuständen.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken)

[creepi]

Benutze kein draw, print oder put innerhalb des threads :/
was ich im thread nutz ist:

imagecreate, line grafik,(...), hex(point(x, y, grafik)), imagedestroy

kommen die befehle / einer der befehle als ursache in betracht?
anzeigen wie gesagt lasse ich es nicht, nach der berechnung, auslesen des hex, wird die erstellte grafik wieder gelöscht.


Edit: hab aber schon weiter oben erwähnt das ich keine anzeige nutze innerhalb des threads, screenlock verwende ich auch nur einmal, also das ist alles im grünen bereich

[nemored]

LINE ist ein Zeichenbefehl, ist also auf jeden Fall gefährlich. Und auch POINT liest vom Grafikspeicher, muss also auch geschützt werden. IMAGECREATE und IMAGEDESTROY sollten meines Erachtens kein Problem darstellen, wenn die Variablen nur lokal sind - aber sicher bin ich nicht.


edit: wobei ... IMAGECREATE ist von der aktuellen SCREENRES-Einstellung abhängig und muss ja irgendwie auf diese zugreifen ...
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[creepi]

Hab gerad mal nachgeschaut was screenres genau ist.
Nutze nur screen in der größe 20 und mit der 32 bit einstellung.

ooook, dachte es hat vielleicht eher was mit den anzeigen zu tun wenn der zugrief ärger macht, *denk*, mmmmmmh dann darf im hauptprogramm und im thread nicht gleichzeitig auf ein grafikbefehl zugegriffen werden, könnte man sagen?

Bevor ich im hauptprogramm put oder... nutze prüfen ob im thread gerade auf line..... zugegriffen wird. Werd ich mal versuchen ob es dann läuft

Muss ich zwar jetzt paar sachen ändern aber bin gespannt ob es das war, wenn ja hat es sich gelohnt. Aaaauch sich hier zu melden, hab da schon eine weile dran rum probiert und wollt scho früher aber naja ; )

Also, ich probiere es jetzt mal... erstelle ein neuen mutex für grafikanwendungen, drückt mir mal die daumen

so am rande, ihr seid echt klasse : D
Statt einen klein zu reden/dumm hinzustellen oder so..., hilfsbereit
ziehe mein hut vor euch.


Edit: also manchmal......... kommando zurück. Also gleichzeitiger zugriff auf den grafikspeicher findet bereits nicht statt. Hab doch screenlock gesichert, sobald screenlock aktiv ist greift der thread nicht auf imagecreate & line zu.... ergo, am gleichzeitigen zugriff liegt es nicht.

Also könnte man hingehen und behaupten bereits der zugriff auf den grafikspeicher innerhalb des threads führt zu problemen??
Aber glaub so wurd es weiter oben auch schon angedeutet, hab wohl gehofft es gibt da noch eine lösung

Ich schau mal ob es flüßig bleibt wenn ich andere aufgaben in den thread verlege und die aufgabe mit dem imagecreate ins hauptprogramm verfrachte, vielleicht wäre das eine lösung schon mal

[grindstone]

Hallo creepi!

Ich fürchte, du hast eine falsche Vorstellung von der Funktion von ScreenLock. ScreenLock verhindert nur, daß der Inhalt des Grafikspeichers unmittelbar auf dem Bildschirm angezeigt wird. Auf Lese-/Schreibzugriffe auf den Grafikspeicher hat dieser Befehl keinen Einfluss.

Außerdem mußt du, wenn du mit Threads arbeitest, immer im Hinterkopf behalten, daß das Hauptprogramm (das ja im Grunde auch nichts anderes als ein Thread ist) und der/die Thread(s) völlig asynchron laufen. Es sind quasi zwei (oder mehr) verschiedene Programme, die gleichzeitig laufen und sich dabei denselben Speicherbereich teilen, und welches davon wann und in welchem Prozessorkern läuft, wird vom Betriebssystem geregelt. Deshalb mußt du als Programmierer dafür sorgen, daß die jeweiligen Speicherzugriffe nicht miteinander kollidieren können.

Wenn du genaueres darüber erfahren willst, empfehle ich dir
http://www.freebasic-portal.de/tutorials/mutexe-54.html und
http://www.freebasic-portal.de/projekte/openbook-2d-spieleprogrammierung-59.html.

Und noch einmal: Die Benutzung eines Grafikbefehls hat die gleiche Wirkung wie der Zugriff auf eine globale Variable.

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[creepi]

Jau, das war der knack punkt, mir war nicht bewusst das die grafikbefehle wie die variablen geschützt werden müssen.

Das mit screenlock war mir bewusst, hatte es per cls im test-prog zum absturz gebracht und dachte da wäre der fehler gewesen aber imagescreate und oder line haben ebenfalls ein crash verursacht, sowie das flackern.

Hab nun alles soweit umgebaut das der code im hauptprogramm durch gearbeitet wird. Damit kein ruckeln zu stande kommt hab ich es nun so geregelt das alle 10ms auf den code zugegriffen wird, läuft nu so auch flüssig : P
uuuund ich mach mir da über eine woche nen kopf mit dem blöden thread ;D
zwar dauert die berechnung nun länger aber egal...

Was den thread anbelangt, hab da nun "nur" ein shared zähler eingebaut.
Der läuft und läuft und läuft, hab nun bissel gespielt, kein flackern, kein crash und der zähler ist gerade bei 75000+
(ebenfalls alle 10ms hab die funktion mit condsignal eingebaut und gehoft das ich es so auf die reihe bekomme... werd es aber lassen und mal später versuchen andere berechnungen dort rein zu basteln

nun ist jedenfalls klar woran es gelegen hatte *happy*
Merke: Verwende keine grafikbefehle in ein thread : D


PS. evtl. den hinweis noch bei der erklärung vom thread-befehl reinhauen. Weil da hatte ich mich durch gewühlt was thread anbelangt. Soweit ich mich erinner spontan, stand da nichts das grafikbefehle probleme machen. Mein ja nur falls es anderen auch so gehen sollte, falls version 0.91 noch etwas zeit in anspruch nimmt wäre das ja ggf. eine lösung für zukünftige, ich hatte mir die zähne dran ausgebissen tag & nacht ;DDDD
Aaalso, ich dacht zb. an hier: http://www.freebasic-portal.de/befehlsreferenz/threadcreate-273.html
am besten mit rotstift das es auch ins auge fällt : )

Naaaa gut, jetzt kann die arbeit weitergehen

[Jojo]

[grindstone]

Na ja, daß es sich beim Grafikspeicher quasi um eine globale Variable handelt, ist zwar logisch, dürfte aber jemandem, der sich noch nie damit befasst hat, nicht bewusst sein. Ich hatte ja seinerzeit die gleichen Probleme mit rätselhaften und nicht reproduzierbaren Programmabstürzen...

Ein entsprechender Hinweis in der Befehlsreferenz bei "ScreenRes" und "Screen" (beim Konsolenfenster gibt es diese Probleme ja nicht) könnte da schon hilfreich sein.

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[Jojo]