| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
ALWIM
Anmeldungsdatum: 08.08.2006
Beiträge: 1048
Wohnort: Niederbayern
|
 Verfasst am: 09.06.2015, 21:10 Titel: Mutex richtig einsetzen? |
 |
|
Kann mir jemand etwas über Mutexe sagen?
Es gibt zwar den Artikel auf Freebasic-portal.de, aber ich bin da noch etwas am grübeln.
Ich habe die TSNE Bibliothek im Einsatz und wenn ich da Daten von dem anderen Rechner empfange, hängt sich mein Programm auf.
Es werden auf Tastendruck zuerst ein Unterprogramm aufgerufen, dann Daten zum anderen Rechner (Rechner 2) gesendet; ausgewertet und bei Bedarf neue Daten zurück zum Rechner 1 gesendet.
Ich befinde mich in so einer Schleife:
| Code: | DO
IF MULTIKEY(&h..) THEN GRAFIK: SENDEN
LOOP
SUB Grafik
' Grafik zeichnen
END SUB
|
Nun ist es so, dass die SUB TSNE_NEWDATAUDP auch das Unterprogramm GRAFIK aufruft.
Wie setze ich da jetzt das MUTEX am besten ein, so dass das Programm sich nicht mehr aufhängt? Auf was muss ich achten? Was brauche ich alles?
Die andere Frage die sich mir noch stellt: Was ist bei einem Rechner der nur 1 Thread/Kern besitzt? Funktioniert das dann?
_________________
SHELL SHUTDOWN -s -t 05 |
|
| Nach oben |
|
 |
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 10.06.2015, 07:43 Titel: Re: Mutex richtig einsetzen? |
|
|
| Code: | DO
mutexlock(...)
IF MULTIKEY(&h..) THEN
GRAFIK
mutexunlock(...)
SENDEN
else
mutexunlock(...)
end if
LOOP
SUB Grafik
' Grafik zeichnen
END SUB
SUB TSNE_NewData(.......)
mutexlock(...)
Grafik()
mutexunlock(...)
END SUB
|
| Zitat: | | Die andere Frage die sich mir noch stellt: Was ist bei einem Rechner der nur 1 Thread/Kern besitzt? Funktioniert das dann? |
Jip .. funzt auch dann. Das verwaltet das Betriebssystem, nicht der Prozessor.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
ALWIM
Anmeldungsdatum: 08.08.2006
Beiträge: 1048
Wohnort: Niederbayern
|
| Verfasst am: 10.06.2015, 22:31 Titel: |
|
|
Wie ist es mit dem Befehl Screenlock bzw. Screenunlock? Habe das Gefühl, dass der dafür sorgt, dass sich das Programm trotzdem aufhängt? Bei einem ersten Test konnte ich das feststellen!
Programm hängt sich momentan immer noch auf. Hat aber schon mal funktioniert? Konnte das Programm bei ersten Test's ohne Probleme (kurzfristig) laufen lassen. Keine Ahnung was man alles mit einem Mutex versehen muss?
Ich danke schon mal für die Hilfe!
Gruß
ALWIM
_________________
SHELL SHUTDOWN -s -t 05 |
|
| Nach oben |
|
|
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 11.06.2015, 10:35 Titel: |
|
|
Hallo,
Wenn Du etwas auf den Bildschirm Zeichnest, z.B. Linien, Kreise oder Bilder, dann verhindert Screenlock nur das das zeug direkt in den Bildschirmspeicher gezeichnet wird.
Erst mit ScreenUnLock wird ein Update durchgefuehrt so das das neue Bild sichtbar wird.
Wenn jetzt vergessen wird, nach einem ScreenLock, ScreenUnLock auf zu rufen, kann es schon so Aussehen als ob das Programm haenkt.
Schau's Dir nochmal genau an http://www.freebasic-portal.de/befehlsreferenz/screenlock-370.html |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 11.06.2015, 11:10 Titel: |
|
|
Dazu sei gesagt dass Screenlock natürlich genau dasselbe ist wie Mutexlock und Mutexunlock mit einem speziellen Mutex. Wenn du also munter mit zwei verschiedenen Mutexen (also deinem eigenen und Screenlock) arbeitest, ohne dir die Reihenfolge davon zu überlegen, kann es schnell zu Deadlocks kommen. Beispiel:
| Code: |
Thread 1:
Screenlock
Mutexlock(x)
....
Mutexunlock(x)
Screenunlock
|
| Code: |
Thread 2:
Mutexlock(x)
Screenlock
....
Screenunlock
Mutexunlock(x)
|
Dieser Code wird irgendwann deadlocken, weil evtl z.B. zwischen den ersten beiden Zeilen in Thread 1 ein Kontextwechsel stattfindet. D.h. der Screen ist dann schon gelockt, aber noch nicht dein eigener Mutex. Thread 2 wird ausgeführt und lockt den Mutex, er ist ja noch nicht gelockt. Thread 2 versucht dann den Screen zu locken, aber der ist schon gelockt, er muss also warten bis der Screen geunlockt wird. Also wechselt das System wieder zu Thread 1, der nun deinen Mutex nicht mehr locken kann, weil ja Thread 2 das grade eben getan hat. So warten die Threads nun munter aufeinander bis sie blau werden.
-> Als grundlegende Richtlinie müssen verschachtelte Mutexe in allen Threads derselben Reihenfolge gesperrt werden!
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 11.06.2015, 18:48 Titel: |
|
|
| Seit 1.00.0 sollten Grafikbefehle threadsafe sein, ein Mutex hierfür sollte also nicht nötig sein. |
|
| Nach oben |
|
|
ALWIM
Anmeldungsdatum: 08.08.2006
Beiträge: 1048
Wohnort: Niederbayern
|
| Verfasst am: 11.06.2015, 20:56 Titel: |
|
|
| MOD hat Folgendes geschrieben: | | Seit 1.00.0 sollten Grafikbefehle threadsafe sein, ein Mutex hierfür sollte also nicht nötig sein. |
Das klingt interessant, sofern es das ist was ich meine. ??? Das würde also bedeuten, dass ich kein Mutex mehhr brauche, wenn ich Grafikbefehle einsetze? Bloß gibt es mit der TSNE-Bibliothek Probleme, bei der neuesten Freebasicversion. Zumindest war es so, als ich das getestet habe.
Gruß
ALWIM
_________________
SHELL SHUTDOWN -s -t 05 |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4699
Wohnort: ~/
|
| Verfasst am: 11.06.2015, 21:00 Titel: |
|
|
SCREENLOCK ist sowieso nicht empfehlenswert, wenn es in der gesperrten Zeit zu Wartezeiten kommt (also z. B. auf ein Mutex gewartet werden muss). Bei der Version
| Code: | Screenlock
Mutexlock(x)
....
Mutexunlock(x)
Screenunlock |
sollte es meines Wissens sowieso früher oder später zu Problemen kommen.
| Befehlsreferenz hat Folgendes geschrieben: | | Unter Win32 und Linux wird der Bildschirm gesperrt, indem der Thread gestoppt wird, der auch für die Events des Betriebssystems zuständig ist. Wenn der Bildschirm für längere Zeit gesperrt bleibt, kann das System instabil werden. |
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4699
Wohnort: ~/
|
| Verfasst am: 11.06.2015, 21:03 Titel: |
|
|
| Zitat: | | Das klingt interessant, sofern es das ist was ich meine. ??? Das würde also bedeuten, dass ich kein Mutex mehhr brauche, wenn ich Grafikbefehle einsetze? Bloß gibt es mit der TSNE-Bibliothek Probleme, bei der neuesten Freebasicversion. Zumindest war es so, als ich das getestet habe. |
Es kann halt an allen möglichen Stellen liegen. Sobald du z. B. auf eine Variable zugreifst, auf die beide Threads zugreifen können, muss jeder dieser Zugriffe mutexgeschützt sein.
(übrigens mal schnell am Rande ein Verweis auf http://forum.qbasic.at/viewtopic.php?p=106964#106964)
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
ALWIM
Anmeldungsdatum: 08.08.2006
Beiträge: 1048
Wohnort: Niederbayern
|
| Verfasst am: 12.06.2015, 00:16 Titel: |
|
|
| Zitat: |
C:\Programme\FreeBASIC\fbc -s gui "Test.bas"
F:\MG\TSNE_V3.bi(905) error 41: Variable not declared, opensocket in 'Dim TSock as Socket = opensocket(PF_INET, SOCK_RAW, IPPROTO_ICMP)'
F:\MG\TSNE_V3.bi(925) error 41: Variable not declared, u_long in 'Dim XFlag as Integer = ioctlsocket(TSock, FIONBIO, Cast(Any Ptr, 1))'
F:\MG\TSNE_V3.bi(1029) error 71: Array not dimensioned, before '(' in 'Dim TSock as Socket = opensocket(AF_INET, SOCK_STREAM, IPPROTO_IP)'
F:\MG\TSNE_V3.bi(1089) error 71: Array not dimensioned, before '(' in 'Dim TSock as Socket = opensocket(AF_INET, SOCK_STREAM, IPPROTO_IP)'
F:\MG\TSNE_V3.bi(1154) error 71: Array not dimensioned, before '(' in 'Dim TSock as Socket = opensocket(PF_INET, SOCK_STREAM, 0)'
F:\MG\TSNE_V3.bi(1324) error 71: Array not dimensioned, before '(' in 'Dim TSock as Socket = opensocket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)'
F:\MG\TSNE_V3.bi(1393) error 71: Array not dimensioned, before '(' in 'Dim TSock as Socket = opensocket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)'
F:\MG\TSNE_V3.bi(1803) error 41: Variable not declared, selectsocket in 'selectsocket(TSock + 1, @TFDSet, 0, 0, @TTV)'
Build error(s)
|
Mit neuester Biliothek und FB-Version 1.02.1!
Keine Chance das Ding zum laufen zu bringen!
_________________
SHELL SHUTDOWN -s -t 05 |
|
| Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1278
Wohnort: Ruhrpott
|
|
| Nach oben |
|
|
ALWIM
Anmeldungsdatum: 08.08.2006
Beiträge: 1048
Wohnort: Niederbayern
|
| Verfasst am: 12.06.2015, 01:00 Titel: |
|
|
Hilft auch nicht, leider! Mir bleibt im Moment nichts anderes übrig, als die alte FB-Version zu verwenden! Solange das ganze nicht ordnungsgemäß funktioniert, kann ich keine neue Compilerversion verwenden. 
Ne andere Frage:
Wie kriege ich das Flackern ohne Screenlock weg? Vorallem wenn ich Screenlock nicht einsetzen soll?
Gruß
ALWIM
_________________
SHELL SHUTDOWN -s -t 05 |
|
| Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1278
Wohnort: Ruhrpott
|
| Verfasst am: 12.06.2015, 11:54 Titel: |
|
|
Eventuell mit 2 Bildschirmseiten und mithilfe von "ScreenCopy" und "ScreenSet". Das ist aber ziemlich umständlich, und ob es wirklich funktioniert, hängt von der Anwendung ab.
Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
