Threading

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	IonPainter Betreff: Threading	Do, Apr 20, 2006 20:40 Antworten mit Zitat
Hallo, hab mich mal etwas mit Threading unter Bmax auseinandergesetzt und bin dabei auf folgendes Modul gestoßen: http://blitzbasic.com/Communit...opic=48782 Nun hab ich selbiges heruntergeladen, kompiliert, etc. Klappt auch alles wunderbar bis auf das eigentliche Threading: Code: [AUSKLAPPEN] [EINKLAPPEN] Global thread_ret Global non_thread_ret Graphics 640,480,0 thread = CreateThread(call_thread_function) While Not KeyDown(KEY_ESCAPE) Cls call_non_thread_function() DrawText "threaded "+thread_ret,10,10 DrawText "non threaded "+non_thread_ret,10,30 Flip Wend End Function call_thread_function() Repeat thread_ret = thread_ret + 1 Delay 1 Forever End Function Function call_non_thread_function() non_thread_ret = non_thread_ret + 1 Delay 1 End Function Der Code ist das beiliegende Sample etwas umgeändert. Ich frage mich nun warum die Schleife im Thread ( 'call_thread_function()' ) das ganze Programm (zumindest bei mir) anhält, und ich nur mit dem roten Knopf wieder Herr der Lage werden kann. Soweit ich etwas von der Materie verstanden habe sollte doch der Thread völlig unabhängig von dem Hauptprogramm laufen, im Idealfall bei einem Multicore-System auf der n-ten CPU. Korrigiert mich wenn ich was falsch verstanden habe, dieses Problem lässt mich nicht mehr los mfg, Ion.

IonPainter

Betreff: Threading

Do, Apr 20, 2006 20:40
Antworten mit Zitat

Hallo,

hab mich mal etwas mit Threading unter Bmax auseinandergesetzt und bin dabei auf folgendes Modul gestoßen: http://blitzbasic.com/Communit...opic=48782

Nun hab ich selbiges heruntergeladen, kompiliert, etc. Klappt auch alles wunderbar bis auf das eigentliche Threading:

Code: [AUSKLAPPEN]

Global thread_ret
Global non_thread_ret

Graphics 640,480,0

thread = CreateThread(call_thread_function)

While Not KeyDown(KEY_ESCAPE)

Cls

call_non_thread_function()

DrawText "threaded "+thread_ret,10,10
DrawText "non threaded "+non_thread_ret,10,30


Flip

Wend

End

Function call_thread_function()

Repeat

   thread_ret = thread_ret + 1


   Delay 1

Forever

End Function

Function call_non_thread_function()

   non_thread_ret = non_thread_ret + 1


   Delay 1

End Function

Der Code ist das beiliegende Sample etwas umgeändert. Ich frage mich nun warum die Schleife im Thread ( 'call_thread_function()' ) das ganze Programm (zumindest bei mir) anhält, und ich nur mit dem roten Knopf wieder Herr der Lage werden kann. Soweit ich etwas von der Materie verstanden habe sollte doch der Thread völlig unabhängig von dem Hauptprogramm laufen, im Idealfall bei einem Multicore-System auf der n-ten CPU.

Korrigiert mich wenn ich was falsch verstanden habe, dieses Problem lässt mich nicht mehr los Smile

mfg, Ion.

	rema	Do, Apr 20, 2006 21:26 Antworten mit Zitat
Mark hat gesagt das BlitzMax nicht Threadingkonform ist. Habe selber das Modul für MacOS angepasst (von Linux her). Also, das ganze läuft auf eigene Gefahr, bzw gibt es keine Gewährleistung das es überhaupt laufen muss. Aber schau mal hier rein: https://www.blitzforum.de/foru...ght=thread

rema

Do, Apr 20, 2006 21:26
Antworten mit Zitat

Mark hat gesagt das BlitzMax nicht Threadingkonform ist. Habe selber das Modul für MacOS angepasst (von Linux her).

Also, das ganze läuft auf eigene Gefahr, bzw gibt es keine Gewährleistung das es überhaupt laufen muss.

Aber schau mal hier rein: https://www.blitzforum.de/foru...ght=thread

	IonPainter	Do, Apr 20, 2006 21:39 Antworten mit Zitat
Habe ich getan und bin irgendwie genauso schlau wie vorher Was ich nicht verstehe ist, das ein Thread den anderen anhält. Das ist doch gerade der Sinn der Sache das die 2 Threads paralel laufen oder nicht? Das ursprüngliche Example läuft auch wunderbar, nur leutet mir da der Sinn nicht ganz ein (dann kann ich ja gleich alles in einen Thread packen). mfg, Ion

IonPainter

Do, Apr 20, 2006 21:39
Antworten mit Zitat

Habe ich getan und bin irgendwie genauso schlau wie vorher Confused

Was ich nicht verstehe ist, das ein Thread den anderen anhält. Das ist doch gerade der Sinn der Sache das die 2 Threads paralel laufen oder nicht?

Das ursprüngliche Example läuft auch wunderbar, nur leutet mir da der Sinn nicht ganz ein (dann kann ich ja gleich alles in einen Thread packen).

mfg, Ion

	Dreamora	Do, Apr 20, 2006 22:18 Antworten mit Zitat
Mehrere Threads können auf einem SingleCore System nicht parallel laufen, da 1 Prozessor nur an einem Thread arbeiten kann auf einmal. Sie können bestenfalls alternierend laufen (heisst immer wieder abwechselnd). Das setzt aber voraus, dass ein Thread auch Mal anhält, mittels WaitEvent zb. Und sobald dann wirklich ein MultiCore / MultiProzessor System vorhanden ist, gehts meist nicht allzulange, bis der GC winke winke macht, weil er auf Ressourcen zugreifen will, die gerade ein anderer Thread verwendet, was dann zum kommentarlosen Absturz führt. (dieser Fall kommt auf einem SingleCore nicht allzuhäufig vor, weil selbst der HT Zusatz von P4 von der Auslastung des Kerns abhängt.) Mutex wären eine Möglichkeit, hätte Mark diese im GC etc vorgesehen. Hoffen wir, dass das mit dem 3D Modul noch kommt, wäre sonst dann wohl vieles, nur definitiv net NextGen ...
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Do, Apr 20, 2006 22:18
Antworten mit Zitat

Mehrere Threads können auf einem SingleCore System nicht parallel laufen, da 1 Prozessor nur an einem Thread arbeiten kann auf einmal. Sie können bestenfalls alternierend laufen (heisst immer wieder abwechselnd).
Das setzt aber voraus, dass ein Thread auch Mal anhält, mittels WaitEvent zb.

Und sobald dann wirklich ein MultiCore / MultiProzessor System vorhanden ist, gehts meist nicht allzulange, bis der GC winke winke macht, weil er auf Ressourcen zugreifen will, die gerade ein anderer Thread verwendet, was dann zum kommentarlosen Absturz führt. (dieser Fall kommt auf einem SingleCore nicht allzuhäufig vor, weil selbst der HT Zusatz von P4 von der Auslastung des Kerns abhängt.)

Mutex wären eine Möglichkeit, hätte Mark diese im GC etc vorgesehen. Hoffen wir, dass das mit dem 3D Modul noch kommt, wäre sonst dann wohl vieles, nur definitiv net NextGen ...

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	rema	Do, Apr 20, 2006 22:32 Antworten mit Zitat
Also, ich habe es nur auf meinem Mac testen können. Bei mir läuft es absolut einwandfrei. Das einzigste was ich festgestellt habe: auch wen Delay in beiden Functions gleich gross ist, so läuft der generierte Thread viel viel schneller als der Parent-Thread. Parent: 1'000 (nontreaded) Child: 12'000 (treaded) Wegen deim Problem. Wie gesagt, unter Windows ist dies sehr problematisch, da Windows so nicht multitreading unterstützt, wie im Gegensatz zu Linux oder MacOSX.

rema

Do, Apr 20, 2006 22:32
Antworten mit Zitat

Also, ich habe es nur auf meinem Mac testen können. Bei mir läuft es absolut einwandfrei.

Das einzigste was ich festgestellt habe: auch wen Delay in beiden Functions gleich gross ist, so läuft der generierte Thread viel viel schneller als der Parent-Thread.

Parent: 1'000 (nontreaded)
Child: 12'000 (treaded)

Wegen deim Problem. Wie gesagt, unter Windows ist dies sehr problematisch, da Windows so nicht multitreading unterstützt, wie im Gegensatz zu Linux oder MacOSX.

	IonPainter	Fr, Apr 21, 2006 1:06 Antworten mit Zitat
Dreamora: Das anhalten hab ich mittels Delay versucht. Ist wohl gehörig schiefgegangen Wenn ich allerdings zwei unabhängige Programme mit BlitzMax erstelle, die weder Delay noch WaitEvent beinhalten und ich beide zur gleichen Zeit ausführe funktioniert alles wunderbar. Der Scheduler vom OS scheint das hinzubekommen, nur meinen zweiten Thread anscheinend (zumindest unter Windows (siehe Posting von rema)) nicht. rema: Das liegt wahrscheinlich daran das in der thread.c in folgender Zeile ein REALTIME zu finden ist: Code: [AUSKLAPPEN] [EINKLAPPEN] SetPriorityClass(&dwThreadId,REALTIME_PRIORITY_CLASS); Mit meinem Halbwissen behaupte ich mal das der Thread eine höhere Priorität zugewiesen bekommt als das Hauptprogramm hat (sogar die höchste überhaupt -REALTIME-). Vielleicht könntest du diese Zeile mal testweise durch: Code: [AUSKLAPPEN] [EINKLAPPEN] SetPriorityClass(&dwThreadId,NORMAL_PRIORITY_CLASS); ersetzen. Hat bei mir unter Windows allerdings nichts gebracht. Bin mir auch nicht sicher ob es damit überhaupt was zu tun hat. mfg, Ion

IonPainter

Fr, Apr 21, 2006 1:06
Antworten mit Zitat

Dreamora:

Das anhalten hab ich mittels Delay versucht. Ist wohl gehörig schiefgegangen Confused

Wenn ich allerdings zwei unabhängige Programme mit BlitzMax erstelle, die weder Delay noch WaitEvent beinhalten und ich beide zur gleichen Zeit ausführe funktioniert alles wunderbar. Der Scheduler vom OS scheint das hinzubekommen, nur meinen zweiten Thread anscheinend (zumindest unter Windows (siehe Posting von rema)) nicht.

rema:

Das liegt wahrscheinlich daran das in der thread.c in folgender Zeile ein REALTIME zu finden ist:

Code: [AUSKLAPPEN]

SetPriorityClass(&dwThreadId,REALTIME_PRIORITY_CLASS);

Mit meinem Halbwissen behaupte ich mal das der Thread eine höhere Priorität zugewiesen bekommt als das Hauptprogramm hat (sogar die höchste überhaupt -REALTIME-). Vielleicht könntest du diese Zeile mal testweise durch:

Code: [AUSKLAPPEN]

SetPriorityClass(&dwThreadId,NORMAL_PRIORITY_CLASS);

ersetzen. Hat bei mir unter Windows allerdings nichts gebracht. Bin mir auch nicht sicher ob es damit überhaupt was zu tun hat.

mfg, Ion

	Dreamora	Fr, Apr 21, 2006 7:50 Antworten mit Zitat
Eher unwahrscheinlich ... unter Windows (zumindest XP), kannst du die Priorität glaub nur auf Prozessbasis vergeben, nicht auf Threadbasis ... ~VERSCHOBEN~ Multithreading is eines der fortgeschrittensten und problematisten Gebiete die es im Moment gibt. Nix Anfängerproblem Dreamora
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Apr 21, 2006 7:50
Antworten mit Zitat

Eher unwahrscheinlich ... unter Windows (zumindest XP), kannst du die Priorität glaub nur auf Prozessbasis vergeben, nicht auf Threadbasis ...

~VERSCHOBEN~

Multithreading is eines der fortgeschrittensten und problematisten Gebiete die es im Moment gibt. Nix Anfängerproblem Very Happy

Dreamora

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	BtbN	Fr, Apr 21, 2006 11:26 Antworten mit Zitat
Mich würde mal interessieren, ob es funktionieren würde, wenn man den GC einfach abschaltet, und Manuel aufruft, wenn man weiß, dass er in Frieden aufräumen kann? Würde das Funktionieren, oder gäbe es da Probleme?

BtbN

Fr, Apr 21, 2006 11:26
Antworten mit Zitat

Mich würde mal interessieren, ob es funktionieren würde, wenn man den GC einfach abschaltet, und Manuel aufruft, wenn man weiß, dass er in Frieden aufräumen kann? Würde das Funktionieren, oder gäbe es da Probleme?

	Dreamora	Fr, Apr 21, 2006 12:11 Antworten mit Zitat
Denke nicht. Der GC arbeitet auch im Hintergrund wenn er nicht aufräumt, da ja noch mehr als nur Aufräumen zu seinem Arbeitsbereich gehört ... Mit dem manuellen collcten kannst du lediglich unnötig verschwendete Zeit durch "aufräumwahn" loswerden.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Apr 21, 2006 12:11
Antworten mit Zitat

Denke nicht.
Der GC arbeitet auch im Hintergrund wenn er nicht aufräumt, da ja noch mehr als nur Aufräumen zu seinem Arbeitsbereich gehört ...

Mit dem manuellen collcten kannst du lediglich unnötig verschwendete Zeit durch "aufräumwahn" loswerden.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	ElWinni Betreff: Threading	Fr, Apr 28, 2006 23:47 Antworten mit Zitat
Hi, Threading unter BlitzMax ist eine Sache mit der man vielleicht erst anfangen sollte sobald die Sprache entsprechend dafür aufgebohrt wurde. Ohne einen multithreading-kompatiblen GC ist es fast vorsätzlicher Suizid überhaupt damit anzufangen, da es nur eine Frage der Zeit ist, bis der GC mit den Speicherzugriffen der anderen Threads kollidiert. In einer multithreaded-Umgebung darf prinzipiell nur synchronisiert auf den Speicher zugegriffen werden, da der Speicher eine geteilte Resource ist. Ähnlich wie bei Datenbanksystemen muß der Zugriff auf den betreffenden RAM-Bereich entsprechend von einem Thread -vor- dem Zugriff darauf für andere Threads gelockt und nach dem Schreibzugriff wieder freigegeben werden. BlitzMax hat hierfür keine impliziten Mechanismen. Xbase++ beispielsweise stellt hierfür Synchronisationsmethoden in der Threadklasse zur Verfügung. Ein weiteres Problem bei Threads ist daß der Ausführungszeit nicht kontrolliert werden kann: Das Betriebssystem bestimmt deren Start, Ende und die Zeitscheibenzuordnung. Nur weil ein Thread im Programm eine Startanweisung erhält, heißt das noch nicht, daß dieser Thread auch sofort startet. Wenn der Hauptthread der Anwendung im Weiteren auf die Existenz des Threads angewiesen ist, muß man ganz sicher weiß daß der Thread auch wirklich schon ausgeführt wird. Übrigens: Auch Windows beherrscht das Prioritisieren von Threads und auch das Setzen einer bestimmten CPU-Affinität. Es macht das nicht erst auf Prozeß-Ebene. Nur am Rande, Linux hat das Multithreading übrigens erst recht spät erlernt. Unixe sind traditionell eher Multiprocessingsysteme, wofür Multithreading keine Voraussetzung ist (andersherum aber ist es zwingend erforderlich). Ich weiß nicht, wie es heute bei Linux implementiert ist, aber in den Anfangstagen war ein Linux-Thread ein normaler Prozeß, der sich aber den Adressraum mit einem anderen Prozeß teilte. Bei der GUI-Programmierung zu beachten: Threads haben (zumindest unter Windows) eigene Event-Queues. Hier ist allerdings mein Disclaimer zu dem Allen: Die meiste Erfahrung habe ich mit Multithreading unter Xbase++ gesammelt, den restlichen Teil unter C#, dort aber nur bei Serveranwendungen. Und eine richtige Threadklasse für BlitzMax fände ich immer noch richtig cool.
-- "And I used to be such a nice guy." - Edward Norton in Fight Club

ElWinni

Betreff: Threading

Fr, Apr 28, 2006 23:47
Antworten mit Zitat

Hi,

Threading unter BlitzMax ist eine Sache mit der man vielleicht erst anfangen sollte sobald die Sprache entsprechend dafür aufgebohrt wurde. Ohne einen multithreading-kompatiblen GC ist es fast vorsätzlicher Suizid überhaupt damit anzufangen, da es nur eine Frage der Zeit ist, bis der GC mit den Speicherzugriffen der anderen Threads kollidiert.

In einer multithreaded-Umgebung darf prinzipiell nur synchronisiert auf den Speicher zugegriffen werden, da der Speicher eine geteilte Resource ist. Ähnlich wie bei Datenbanksystemen muß der Zugriff auf den betreffenden RAM-Bereich entsprechend von einem Thread -vor- dem Zugriff darauf für andere Threads gelockt und nach dem Schreibzugriff wieder freigegeben werden.

BlitzMax hat hierfür keine impliziten Mechanismen. Xbase++ beispielsweise stellt hierfür Synchronisationsmethoden in der Threadklasse zur Verfügung.

Ein weiteres Problem bei Threads ist daß der Ausführungszeit nicht kontrolliert werden kann: Das Betriebssystem bestimmt deren Start, Ende und die Zeitscheibenzuordnung. Nur weil ein Thread im Programm eine Startanweisung erhält, heißt das noch nicht, daß dieser Thread auch sofort startet. Wenn der Hauptthread der Anwendung im Weiteren auf die Existenz des Threads angewiesen ist, muß man ganz sicher weiß daß der Thread auch wirklich schon ausgeführt wird.

Übrigens: Auch Windows beherrscht das Prioritisieren von Threads und auch das Setzen einer bestimmten CPU-Affinität. Es macht das nicht erst auf Prozeß-Ebene.

Nur am Rande, Linux hat das Multithreading übrigens erst recht spät erlernt. Unixe sind traditionell eher Multiprocessingsysteme, wofür Multithreading keine Voraussetzung ist (andersherum aber ist es zwingend erforderlich). Ich weiß nicht, wie es heute bei Linux implementiert ist, aber in den Anfangstagen war ein Linux-Thread ein normaler Prozeß, der sich aber den Adressraum mit einem anderen Prozeß teilte.

Bei der GUI-Programmierung zu beachten: Threads haben (zumindest unter Windows) eigene Event-Queues.

Hier ist allerdings mein Disclaimer zu dem Allen: Die meiste Erfahrung habe ich mit Multithreading unter Xbase++ gesammelt, den restlichen Teil unter C#, dort aber nur bei Serveranwendungen.

Und eine richtige Threadklasse für BlitzMax fände ich immer noch richtig cool. Smile

--
"And I used to be such a nice guy."
- Edward Norton in Fight Club

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Threading

Betreff: Threading

Betreff: Threading