 |
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4704 Wohnort: ~/
|
Verfasst am: 20.03.2012, 12:45 Titel: |
|
|
Die FreeBASIC-Grafikbefehle sind nicht threadsicher, es ist also äußerst wahrscheinlich, dass sie zu Konflikten führen. Mit ASM kenne ich mich nicht aus; inwieweit es hier zu Problemen kommen kann, weiß ich nicht.
Mutexe bringen natürlich nur etwas, wenn jeder notwendige Bereich geschützt ist - z. B. einen Grafikausgabe-Abschnitt zu schützen, während ein anderer ungeschützt bleibt, macht keinen Sinn. Liegt ja in der Natur des Mutex als "wechselseitiger Ausschluss".
Auf der anderen Seite wird sich das Programm auf jeden Fall aufhängen, wenn du einen Mutex sperrst und ihn im selben Thread erneut sperren willst, bevor er entsperrt wurde. Das ist vor allem bei Prozeduren zu beachten, die sich gegenseitig aufrufen - innerhalb einer Sperrung auf keinen Fall eine Prozedur aufrufen, die (möglicherweise) denselben Mutex wieder sperren will. Dass die komplette Routine "RotateScale" im Mutex liegt, könnte ein Problem darstellen; lieber darin nur die relevanten Bereiche schützen (keine Ahnung, wo das nötig ist).
Das sind jetzt nur ein paar mögliche Fehlerursachen. Woran es in deinem Fall genau liegt, kann ich dir nicht sagen. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
arduno
Anmeldungsdatum: 12.05.2011 Beiträge: 252
|
Verfasst am: 20.03.2012, 16:30 Titel: |
|
|
Jup, danke.
Gruss |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 20.03.2012, 20:10 Titel: |
|
|
nemored hat Folgendes geschrieben: | Auf der anderen Seite wird sich das Programm auf jeden Fall aufhängen, wenn du einen Mutex sperrst und ihn im selben Thread erneut sperren willst, bevor er entsperrt wurde. Das ist vor allem bei Prozeduren zu beachten, die sich gegenseitig aufrufen - innerhalb einer Sperrung auf keinen Fall eine Prozedur aufrufen, die (möglicherweise) denselben Mutex wieder sperren will. |
Ist das in FB wirklich so implementiert? Üblicherweise dürfen "critical sections" vom selben Thread sooft betreten werden, wie er will, jedoch müssen sie auch mindestens genau sooft verlassen werden, damit ein anderer Thread darauf zugreifen kann. Wenn ein Thread sich selbst mit einem einzigen Mutex "aussperren" kann, wäre das eine sehr seltsame Implementierung in FB. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4704 Wohnort: ~/
|
Verfasst am: 20.03.2012, 21:53 Titel: |
|
|
Was ich meine, ist so etwas:
Code: | dim as any ptr m = mutexcreate
mutexlock m
print 1
mutexlock m
print 2
mutexunlock m
mutexunlock m
print 3
mutexdestroy m |
Es wird nur die 1 ausgegeben, dann wartet das Programm beim zweiten MUTEXLOCK auf das Entsperren von m (das nicht mehr kommen kann). _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 21.03.2012, 00:34 Titel: |
|
|
Das ist ja sinnlos. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|