spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hmm also relativ threadsicher kann man ein Programm mit hilfe einer bool var machen. Oder Wenn du eine nahc Threads geordnete Log meinst, dann könntest du das mit offsets in der Datei machen.

Zitat von »"Nox"«

Hmm also relativ threadsicher kann man ein Programm mit hilfe einer bool var machen. Oder Wenn du eine nahc Threads geordnete Log meinst, dann könntest du das mit offsets in der Datei machen.

Nah...thats evil.

Mit bool's bekommt man nichts Thread sicher. Das schreiben in einer Datei ist eh Thread sicher. Vom OS schon her. Es erlaubt nämlich nicht das zwei Threads gleichzeitig in eine Datei schreiben. Problem der zweite Thread bekommt ne Fehlermeldung beim öffnen.

Pro Thread eine Log-Datei ist au unsinn. Es ist am besten wenn mehrere Caches anlegst. In die dann geschrieben wird. Zudem sollte jeder Thread eine UID erhalten. Die dann auch mit dem Log ausgegeben wird.

Für die Syncronisierung empfehle ich Critical Sections. Die sind von allen Syncronisationsobjekten die schnellsten und werden au von Linux unterstützt.

Ja ein Buffer. Die STL Arbeitet nur damit. Wenn man einen Buffer ausgeben will. Ruft man eine Flush-Methode auf. Die fester bestandteil der Log-Klasse ist.

Hin und wieder muss man warten. Das ist halt so. Aber mit den Buffern vermeidet man zum einen das Arbeiten mit Offsets und minmiert so das warten. Der Flush leert dann auf einen Schlag den Buffer.

Einen eigenen Log Thread zu starten ist unsinn und kostet mehr als er bringt. Jeder Thread sollte in der Lage sein ins Log zu schreiben.

Meine Erfahrung ist, dass bei mehreren threads sehr viele oder gar die meisten fehler daher kommen, dass Sachen in einer "falschen" Reihenfolge passieren. Daher finde ich es sehr wichtig, alles chronologisch in einer Log zu haben. Ich habe das in BoB tatsächlich mit Critical Sections implementiert .

PS: Da ich u.a. auch Zeitausgaben gemacht habe, habe ich auch einen Cache implementiert. Allerdings nur einen für beide Threads . Ausserdem muss der abschaltbar sein, damit man bei CTDs an die letzte Debugausgabe kommt.

Da wir au mit mehreren Threads arbeiten, haben wir eben au diese Caches. Die Log-Klasse ist dabei nur sowas wie ein Wrapper und ein kleiner Cache. Der Logger ist dann eine eigene Klasse.

Das klappt sehr gut, da nur eine Critical Section beim schreiben notwendig ist. Da die Buffer immer Lokal sind und somit nicht Syncronisiert werden müssen.

Joa...Threads sind immer so ne Sache. bringen viele Performancevorteile. Aber die Fehlerquellen steigen überproportional an.

Zitat von »"Sicaine"«

Hm ich hättes jetzt eher einfach in ne Logdatei geschrieben und ein kleines Debugtool was mir die Logdatei einfach aufsplittet etc.

Nehmen wir an du hast deine Log-Datei jetzt schön aufgeteilt und jeder Thread hat nun Platz in der Datei.

Thread A öffnet nun das Log File. Bevor er ins file schreiben kann, wird er unterbrochen. Thread B will nun ebenfalls etwas ins Log schreiben. Öffnet nun die Log Datei. Bekommt allerdings einen Fehler. Logging wird abgebrochen. Und nu? Thread B muss hier auf Thread A warten bis er das Log file wieder freigibt.

Man könnte natürlich das Log file einmal beim Start öffnen und erst wieder am ende Schließen. Hat aber zwei hacken.

1) Bei einem Programmabbruch ist nicht sichergestellt, das auch alles im Log landet. Im schlimmstenfall ist das File leer (Hatte ich schon oft).
2) Mehrere Threads können willkürhlich ins Log schreiben. Was passiert dann wenn der vorgesehene Raum für as Logging voll ist?

Du hast noch nicht viel mit Threads gearbeitet nehm ich an. Wenn du dann damit anfängst wirst du vieles sehr schnell feststellen. Auch wir musten da sehr viel Lernen, bevor alles richtig lief.