spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das Problem ist ja, das nicht alle Änderungen für alle Clients interessant sind. Auch ist nicht gesagt, dass wenn ein Client eine Nachricht schickt, diese zu einer Änderung führen muss (weil z.B. die Nachricht garnicht ausgeführt werden kann).
Prinzipiell kann man für das Problem jegliche Clientreaktion ausblenden. Wir nehmen also an, dass die Clients nur stille Zuhörer sind und der Server vorsich hin werkelt. Nun muss der Server feststellen welche Daten für einen Client interessant sind und ob der Client die Daten nicht vielleicht schon hat.


(P.S: wenn ich mich recht erinnere sind Datentypen int, bool, char usw. doch atomar und die Operationen ebenfalls oder irre ich mich da?)

Stimmt, dürfte nicht das richtige Wort sein. Die Frage ist halt das Vergleichen bzw. das Setzen ein Variable von sich aus "threadsafe" ist, weil selbst einfachste Vergleichsoperationen bzw. Zuweisungsoperationen schon aus mehreren ASM-Anweisungen besteht.
Ganz konkret:

Thread 1: while(RefCounter == 2)
Thread 2: (nach einiger Zeit) RefCounter--;

Ich sehe zwar oft solche Konstrukte als eine Art Mutex, aber ich bin mir nicht sicher, ob dies wirklich sicher ist. Weil es gibt viele Weg das Risiko zu minimieren, aber das ist ein Spiel der Wahrscheinlichkeiten worauf ich mich nicht einlassen kann. Entweder es ist threadsafe oder eben nicht.
Da ich mich mit ASM nicht auskenne, wüsste ich ob das nun wirklich sicher ist oder nicht.

Okay iwenn bei bool/int gewährleistet ist, dass nur ein Thread schreibt ist also alles in Ordnung?

Ja gut das ist klar :lol: Super ein Problem weniger. Bleiben nur noch 99

Das Problem ist, rauszufinden welche Objekte ein Client braucht. Großes Array ist viel zu sehr zu starr, wofür gibt es Maps . Aber egal ob Map oder Array, ich müsste diese "Verwaltung" bei jedem Zugriff sperren und das kann ich nicht machen. Das Sperren kann ich mal machen aber nicht regelmäßig.

Der Client sagt z.B. ich will jetzt Sektor 3 betreten. Das System muss nun rausfinden, welche Objekte der Client jetzt braucht. Der Fall ist noch einfach, weil ich dann nur alle untergeordneten Objekte brauche. Schwieriger wird es, wenn der Client die Daten aller Objekte braucht, die ihm gehören. Dann muss der Server feststellen in welche Sektoren der Client Objekte besitzt und da wirds knuffig :badgrin: .

Atm verfolge ich die Idee, zwischen den DatenElementen und den ServerClients Verbindungselemente einzubauen. Dann muss ich nur einmal feststellen welche DatenElemente ein Client braucht und nur einmal die Clientliste Locken um sicher zu gehen, dass der Zeiger nicht ungültig wird, während die Verbindungselemente beim Client registiert werden.