 |
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 |
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1280
Wohnort: Ruhrpott
|
 Verfasst am: 23.12.2013, 10:25 Titel: |
 |
|
Und was muß ich machen, um SLEEP threadsicher zu bekommen? In einem Forum fand ich (allerdings für C) den Hinweis | Zitat: | | You should not be sleeping inside a held lock |
was ich durchaus nachvollziehen kann. Ist es das, was du meintest?
Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
| Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1280
Wohnort: Ruhrpott
|
| Verfasst am: 27.12.2013, 03:49 Titel: |
|
|
Hallo allerseits!
Ich habe Colochessum jetzt soweit mit Mutexen gespickt, daß es mit zwei Threads seit einigen Stunden läuft, ohne einzufrieren oder abzustürzen, und ich muß sagen, daß es sehr aufwendig ist. | ThePuppetMaster hat Folgendes geschrieben: | | threadproblematische befehle sind gfx, io und sleep! |
Es fällt nämlich fast die Hälfte aller Befehle unter eine dieser Kategorien.
Darum hätte ich gerne die Anregung von dreael aufgegriffen
| dreael hat Folgendes geschrieben: | | Dazu am besten sämtliche GFX-Aufrufe in eine FreeBasic-Klasse einkapseln |
habe aber eine ganz dumme Frage: Wie geht das? CLASS ist laut Befehlsreferenz (noch) nicht implementiert, und meine weiteren Recherchen haben auch nichts brauchbares ergeben. Kann mir jemand weiterhelfen?
Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4704
Wohnort: ~/
|
| Verfasst am: 27.12.2013, 11:43 Titel: |
|
|
TYPE macht so ziemlich das, was du von CLASS erwartest (incl. Vererbung). Ich weiß jetzt nicht, wie die aktuellen Pläne zu CLASS aussehen - bzw. ob es da überhaupt noch welche gibt - aber so weit ich es verstanden habe, wird es sich dann von TYPE nur darin unterscheiden, ob Records und/oder Methoden standardmäßic PUBLIC, PRIVATE oder PROTECTED sind.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 565
Wohnort: Jüterbog
|
| Verfasst am: 27.12.2013, 11:50 Titel: |
|
|
@grindstone
Quelle: http://beilagen.dreael.ch/QB/ThreadMandelbrot.bas
| Code: |
Type GfxThreadSafe
Private:
mGFX As Any Ptr
Public:
Declare Constructor(x As Integer, y As Integer)
Declare Destructor()
Declare Sub tsPset(x As Integer, y As Integer, f As Integer)
End Type
Constructor GfxThreadSafe(x As Integer, y As Integer)
mGFX = MutexCreate
MutexLock mGFX
ScreenRes x, y, 4
Width x \ 8, y \ 16
MutexUnLock mGFX
End Constructor
Destructor GfxThreadSafe()
MutexDestroy mGFX
End Destructor
Sub GfxThreadSafe.tsPset(x As Integer, y As Integer, f As Integer)
MutexLock mGFX
PSet (x, y), f
MutexUnLock mGFX
End Sub
.
.
.
.
.
Dim Shared bilds As GfxThreadSafe = GfxThreadSafe(640, 480)
.
.
.
.
.
bilds.tsPset x, y, r Mod 15
|
Ich vermute daß dreael folgendes meinte: man kann jetzt noch weitere Methoden ala GfxThreadSafe.tsPset definieren, für jeden
GFX-Befehl eine eigene Methode.
Wenn ein Aufruf einer Methode aus dem Objekt bilds erfolgt, egal aus welchem Thread, ist er in jedem Fall save.
Mich würde aber mal trotzdem die Problematik bezüglich SLEEP genauer interessieren.Ich sehe da so deutlich keine.
Das sie aber nun existiert.... Hmmmm ...
Mutton |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 27.12.2013, 16:56 Titel: |
|
|
@grindstone
Um diese Befehle Threadsafe zu bekommen, musst du einfach dafür sorgen das diese nicht simultan aufgerufen werden können.
Du klammerst diese folglich in ein Mutex ein.
Was jedoch beim "sleep" befehl auch sehr "behämmerte" folgen haben kann. Denn, Gerade Sleep soll eigentlich dafür sorgen, das ein prog nichtganz so viel cpu frist und einem anderen thread etwas mehr resourcen zur verfügung stellt. Allerding wird das durch das Mutex etwas kaput gemacht.
Daher bleibt dir eigentlich für sleep nur der weg über die API, und damit den weg um die fbrtl.
@Muttonhead .... das Sleep problem existiert definitiv unter linux. ob dies unter win ebenfalls so problematisch ist, kann ich nicht sagen.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
dreael
Administrator
Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)
|
| Verfasst am: 27.12.2013, 22:09 Titel: |
|
|
| Muttonhead hat Folgendes geschrieben: | Ich vermute daß dreael folgendes meinte: man kann jetzt noch weitere Methoden ala GfxThreadSafe.tsPset definieren, für jeden
GFX-Befehl eine eigene Methode. |
Siehst Du völlig richtig. Genau so war es auch gemeint von mir. :-))
| Muttonhead hat Folgendes geschrieben: | | Wenn ein Aufruf einer Methode aus dem Objekt bilds erfolgt, egal aus welchem Thread, ist er in jedem Fall save. |
Genau das mache ich bereits im Thread-Mandelbrotbeispiel, klappt auf alle Fälle dort fehlerfrei, d.h. jeder dort je für eine Pixelzeile zuständige Thread darf zeichnen, muss aber warten, bis ein evtl. bereits zeichnender Thread mit seiner Arbeit fertig ist, wofür der Mutex in der GFX-Einkapselungsklasse sorgt.
| Muttonhead hat Folgendes geschrieben: | Mich würde aber mal trotzdem die Problematik bezüglich SLEEP genauer interessieren.Ich sehe da so deutlich keine.
Das sie aber nun existiert¨. |
Siehe mein erstes Beispiel mit den Zählern, d.h. SLEEP ist für Threads bestens geeignet und gibt die CPU frei für andere Threads (und auch Prozesse im Betriebssystem), die gerade etwas zum Erledigen haben.
_________________
Teste die PC-Sicherheit mit www.sec-check.net |
|
| Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010
Beiträge: 1280
Wohnort: Ruhrpott
|
| Verfasst am: 30.12.2013, 23:28 Titel: |
|
|
Hallo!
Vielen Dank für die zahlreichen Hinweise, speziell an nemored und Muttonhead.  Ich bekomme zwar langsam eine Ahnung, wie die Sache funktioniert, aber bis ins Letzte verstanden habe ich es noch nicht. Ist irgendwie alles um 3 Ecken. 
@dreael: Ich habe fast einen ganzen Tag mit dem Mandelbrotprogramm herumgespielt. Ist echt faszinierend! 
@ThePuppetMaster:
| Zitat: | Um diese Befehle Threadsafe zu bekommen, musst du einfach dafür sorgen das diese nicht simultan aufgerufen werden können.
Du klammerst diese folglich in ein Mutex ein. |
Ich habe es auch mit diesem Ansatz versucht:
| Code: | Dim Shared mGFX As Any Ptr
mGFX = MutexCreate
Sub sScreenRes (x As Integer, y As Integer, f As Integer)
MutexLock mGFX
ScreenRes x, y, f
MutexUnLock mGFX
End Sub
#Undef ScreenRes
#Define ScreenRes sScreenRes
Function sInKey () As String
MutexLock mGFX
sInKey = InKey
MutexUnLock mGFX
End Function
#Undef InKey
#Define InKey sInKey
... |
und es scheint zu funktionieren. Vielleicht erstelle ich einmal eine .bi, in der alle fraglichen Befehle abgesichert werden (auch wenn das bei "Print" nicht so einfach sein dürfte).
Beim Colochessum werde ich trotzdem erst einmal versuchen, ohne Threads auszukommen, das Programm ist schon zu komplex, um es nachträglich abzusichern, ohne daß sich dabei neue Fehler einschleichen.
Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
| 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.
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
