spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

WaitForThread fehlt noch. Die Methoden der Klasse CriticalSection würde ich so wie sie jetzt sind durchweg als inline definieren, wobei man hier sich über den Sinn der Kapselung streiten kann.
static DWORD WINAPI threadproc(void*); würde ich wohl ersetzen durch LPTHREAD_START_ROUTINE threadproc; und start gegebenfalls auch um den entsprechenden Zeiger erweitern. Bzw. ist es fraglich, ob man dann noch den Zeiger in der Klasse braucht. Alternativ kann man die threadproc auch dem Konstruktor schon übergeben.

Interessant wäre auch ein Nachrichtensystem, welches zur Kommunikation zwischen Thread und Hauptthread und/oder andere Threads ermöglich. Die lässt sich z.B. über eine Callback-Funktion + Threadingsichere Liste machen.

Zum Thema Zeiger folgender Gedankengang:
Hauptthread: wenn ein Zeiger gültig ist und greift der Thread auf ihn zu
Nebenthread: erstellt ein neues Objekt und speichert die Adresse direkt im Zeiger, löscht es dann wieder und setzt den Zeiger dannach auf NULL.

Was ist nun wenn der Nebenthread den Zeiger erstellt und wieder gelöscht hat, der Hauptthread dann wieder die Kontrolle bekommt und den Zeiger prüft, der zwar gelöscht aber nicht genullt wurde?

Generell gilt eigentlich beim Threading(meine personliche Erfahrung, nicht mehr): Möglichst wenig Objekte haben, die von unterschiedlichen Threads erreicht werden können. Dies mag zwar manchmal zu einen gewissen Overhead führen, aber jeder Lock-Aufruf kostet mehr Zeit als ein gut strukturierter Overhead.

K, thx Gibts eine Möglichkeit zu Überprüfen ob ein anderer Thread noch läuft? Im Moment hängt sich mein Progi immer auf, sobald ein Thread unerwartet endet.

GetExitCodeThread

Jo geht, danke!

Zitat von »"FlyingDragon"«

Ich hab mal in der Zwischenzeit zu meinem letzen Beitrag ein kleines Projekt mit einer Thread-KLasse und einer CriticalSection-Klasse gestartet. Ich bin für Kritik sehr dankbar. Hier der Link: http://dragon.w031.de/trash/threading.zip

Zitat

Was mich vor allem interessieren würde ist, ob einfache Getter und Setter gesperrt werden sollten. Eigentlich doch eher nicht oder, bei einer Anweisung?

Kommt drauf an. Bei den Standardvariablen und Zeigern würde ich keine Bedenken haben. Problematisch kann es bei Stings werden. Da diese Zeichenweise mit einer Schleife kopiert werden. Aber bei get-Methoden sollten man eigentlich kein Problem haben.

Du solltest dafür sorgen das der kritische Breich entsperrt wird falls er unerwartet (durch einen Fehler z.B.) verlassen wird. Es kann ja sein das dein leave() nicht erreicht wird und schon hast du ein Problem.

Außerdem solltest du evtl noch eine Mutexklasse als Prozessübergreifendes Sperrobjekt mit einfügen, kritische Bereiche sind nämlich nur für den Prozessinternen Gebrauch gedacht.

Und ich denke viele würden eine Erklärung von Semaphoren und Events gutheisen!

grüße

Ich finde dieses Tutorial bisher echt gut gemacht. Mein Kompliment an dich. Selbst Neulinge werden hier bald die Grundfunktionen verstehen!

mfg Markus

hallo

ich wollte nur kurz ne frage stellen..

bevor ich das mit den critical sections veruscht habe, wollte ich wissen was die console ausgibt wenn mans falsch macht, da das beispiel bild bei mir nicht angezeit wird (falls das eines ist)

und naja.. irgendwie gibt die console alles korrekt aus .. ?!

sollten da nicht sowas wie ein kleines chaos entstanden sein?

nun wenn man 2 oder mehrere thread parallel laufen lässt und die regelmäßig was in die con. ausgeben, kann und sollte es durhcaus passieren, dass der eine grade eine nachricht schreibt, und dann der 2. einfach seine nachricht da hin printet.(Wenn net ist das warscheinlich zufall, ich hoffe ich habe dein problem verstanden)


Socke