PureBoard

Ok bitte teste es nochmal in der ersten Änderung hatte ich vergessen die Threads zu beenden vor Programmende und es dann nochmals geändert. Jetzt geht es.

captain_hesse hat geschrieben:Ok bitte teste es nochmal in der ersten Änderung hatte ich vergessen die Threads zu beenden vor Programmende und es dann nochmals geändert. Jetzt geht es.

Es ist dokumentiert, das es nicht funktioniert, jedenfalls nicht sicher und Tests haben bei Threads keinen Sinn, man kann es ja nicht steuern, das sich die Thread gegenseitig in Speicher schreiben, der in einem undefinierten Zustand ist. Das es funktioniert, ist trotz
allem nur Zufall, der nur so lange gültig ist, bis es kracht. Und nach Murphy wird es in diesem Zusammenhang krachen

Mag ja sein aber in diesem Programm hier wurde der Fehler dadurch erzeugt daß das Programm nicht richtig beendet wurde.
Ich habe es jetzt X mal getestet bei der neuen Version kommt kein Fehler mehr und bei der Ursprünglichen Version kommt der Fehler andauernd. Wenn es so wäre wie du sagst müßte die Fehlerquote doch gleich bleiben oder ?

captain_hesse hat geschrieben:Wenn es so wäre wie du sagst müßte die Fehlerquote doch gleich bleiben oder ?

Nein, Du hast das ganze zwar abgeschwächt, aber nichts an der Tatsache geändert, das es nicht Threadsafe ist oder jemals sein wird.
Die gemeinsamen Objecte der DirectX Lib sind nicht abgesichert, also nicht Threadsafe. Daran kann keiner von uns was ändern, lediglich
Microsoft könnte das, die werden es aber nicht tun, da DirectX ansonsten zu langsam wird.

Wann zwei nebenläufige Thread nun zufällig auf dieselbe gemeinsame Resource zugreifen, wenn diese in einem undefinierten Zustand ist,
darauf hat auch keiner von uns einfluss. Das kann jedes mal sein oder erst beim 10000sten Start. Das ist aber auch egal, es ist
dokumentiert, das DirectX nicht Threadsafe ist, somit machen Tests keinerlei sinn, solcher Code ist unprofessionell und gefährlich, da
er das ganze System mitreissen könnte und somit riesen Schaden anrichten (wahrscheinlich eher nicht an Deinem Home-PC ).

Egal was Du noch änderst und wieviele Tests Du durchführst, es ändert rein gar nichts! Warum muß ich mich eigentlich laufend wieder-
holen, drücke ich mich so unklar aus?

Gruß
Thomas

Also nochmal IN DIESEM PROGRAMM WIRD DER FEHLER NICHT DURCH DIRECT X VERURSACHT SONDERN DADURCH DAß DAS PROGRAMM NICHT ORDNUNGS BEENDET WURDE und da redest du die ganze Zeit drum herum. Außerdem finde ich es auch nicht unbedingt unprofessionell eine Maus oder Tastaturabfrage in einen Thread Auszulagern in zeitkritischen Schleifen macht das durchaus schon mal sinn. Und außerdem ist da auch nicht groß was dokumentiert da steht nur

Hinweis: Benutzen Sie innerhalb von Threads kein DirectX (MS Windows Einschränkung)! Wenn Sie auf Grafikdarstellung in Threads angewiesen sind, verwenden Sie stattdessen Images und 2DDrawing.

Welche Befehle aber davon betroffen sind steht da nicht. Und das ganze nur abgeschwächt ist ja wohl völliger Quatsch warum sollte der Fehler durch meine Änderungen jetzt nur noch ganz selten bis gar nicht auftreten. Das was ich geändert habe behebt den tatsächlichen Fehler und das ist Fakt. Das der Fehler durch die Verwendung von DX befehlen in einem Thread verursacht wurde ist bisher leider nur Spekulation.

captain_hesse hat geschrieben:Das der Fehler durch die Verwendung von DX befehlen in einem Thread verursacht wurde ist bisher leider nur Spekulation.

Noch nicht mal das, lediglich das diese Möglichkeit dadurch gegeben ist, das DirectX nicht Threadsafe ist, macht den Code und jeden
Test überflüssig.

Also fassen wir nochmal zusammen.
Der Fehler, der beim Drücken von ESC auftrat, war einfach nur, dass der Screen geschlossen wurde, bevor alle DirectX-Operationen ordnungsgemäß beendet wurden.

Dadurch tritt jetzt in ein paar Tests anscheinend kein Fehler mehr auf. Dennoch darf man DirectX-Operationen nicht in anderen als dem Hauptthread ausführen. Zu den DirectX-Operationen gehören alle Befehle aus den Bibliotheken "Sprite", "Keyboard", "Mouse", und alles, was mit 3D zu tun hat.

ts-soft hat geschrieben:Nein, Du hast das ganze zwar abgeschwächt, aber nichts an der Tatsache geändert, das es nicht Threadsafe ist oder jemals sein wird.
Die gemeinsamen Objecte der DirectX Lib sind nicht abgesichert, also nicht Threadsafe. Daran kann keiner von uns was ändern, lediglich
Microsoft könnte das, die werden es aber nicht tun, da DirectX ansonsten zu langsam wird.

(Unterstreichungen der größten Schnitzer wurden von mir hinzugefügt)

Ein kleines Wissensupdate für ts-soft:

- Threading Differences between Direct3D Versions:

Differences between Direct3D 11, 10 and 9:
Direct3D 11 defaults to mostly thread-safe and continues to allow applications to opt-out using D3D11_CREATE_DEVICE_SINGLETHREADED.
If applications opt-out of being thread-safe, they must adhere to threading rules. The runtime synchronizes threads on behalf of the application
allowing concurrent threads to run. In fact, the synchronization in Direct3D 11 is more efficient than using the thread-safe layer in Direct3D 10.

Direct3D 10 can support the execution of only one thread at a time. Direct3D 10 is fully thread safe and allows an application to opt-out of that behavior
by using D3D10_CREATE_DEVICE_SINGLE_THREADED.

Direct3D 9 does not default to thread safe. However, when you call CreateDevice or CreateDeviceEx to create a device,
you can specify the D3DCREATE_MULTITHREADED flag to make the Direct3D 9 API thread safe.
This causes significant synchronization overhead. Therefore, making the Direct3D 9 API thread safe is not recommended
because performance can be degraded.

Naja, dann stimmen meine Aussagen ja wenigstens bezüglich DirectX 9 und DX11 ist in PB ja noch nicht voll unterstützt,
wenn mich nicht alles täuscht.

Müsste ja bald mal als Standard kommen (7 -> 9 -> 11)