Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

05.08.2006, 23:35

Threads - shared Memory

Ich bastel momentan ein einer C++ Klasse die für die Kommunikation zwischen Server und Client zuständig sein soll.
U.a. wird dabei der Server initialisiert (bind, listen, etc) und, da es mehrere Clients geben soll, werden die verschiedenen Sockets verwaltet.
Das Problem dabei ist natürlich, daß das das Programm nichtmehr viel tut wenn ich in einer Schleife neue Verbindungen akzeptiere ( mit accept :-)).

Mein erster Gedanke war folgender:
Ich starte einen neuen Thread, geb ihm einen Zeiger mit durch den er im Speicherbereich des alten Threads die neuen Sockets speichern kann, und laße ihn einfach nur die Verbindungen akzeptieren.

Das Problem liegt dabei im gemeinsam genutzten Speicherbereich; schließlich muß dieser für ThreadX gesperrt werden wenn ThreadY darauf zugreifen will, ansonsten riskiert man Inkonsitenzen.

Aber wie realisiere ich das?
Ich habe mal unter Linux einen Ringbuffer mit Semaphoren zur IPC geschrieben, aber eigentlich sollte es da schon Mechanismen dafür geben, oder?

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

2

05.08.2006, 23:50

Um zu verhindern, dass zwei Threads gleichzeitig auf dieselben Objekte zugreifen, kann man Mutex-Objekte verwenden. Wenn du eine plattformunabhängige Lösung willst, dann empfehle ich dir boost::thread.
http://www.boost.org/doc/html/threads.html

Anonymous

unregistriert

3

06.08.2006, 00:40

Geht doch nichts über die guten alten Mutex ;) Besseres gibt es gar nicht.

4

06.08.2006, 00:53

@David

Danke. Das Stichwort Mutex war gut.

Dadurch bin ich darauf aufmerksam geworden.

In meinem Fall fahre ich aber wohl mit einem Critical-Section Object besser.

5

06.08.2006, 20:28

Mein Shared-Memmory Problem habe ich gelöst, aber dabei bin auf folgende Ungereimtheit gestoßen:

Ich habe eine Singleton Klasse mit einem struct als private Membervariable.
Warum liegt diese Variable im Konstruktor an einer anderen Addresse als in den normalen Methoden?

Darauf bin ich gestoßen als ich versucht habe die Variable als CriticalObject im Konstruktor zu initialisieren, und daraufhin bei jedem Aufruf von EnterCriticalObject in den Methoden eine Speichezugriffsverletzung bekommen habe.

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

6

06.08.2006, 20:37

Kannst du mal ein möglichst kleines Beispiel posten, welches dies demonstriert?

7

06.08.2006, 21:12

gerne :D

ccNet.h

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
class ccNet
{
private:
     eigenesStruct Var    //private Member


     ccNet();

public:
     int methode1();
};


ccNet.cpp

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
ccNet::ccNet()
{
std::cout << &this->Var << std::endl; // Gibt eine Addresse aus

};

ccNet::methode1()
{
std::cout << &this->Var << std::endl; // Gibt eine andere Addresse aus

}



Die Klasse ist wie gesagt eine Singletonklasse und wird als statische Library exportiert.

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

8

06.08.2006, 22:56

Eigentlich dürfte das nicht sein.
Mach mal in den Konstruktor eine Ausgabe rein wie ("Objekt erzeugt: " << this). Wahrscheinlich wird nämlich mehr als nur 1 Objekt erzeugt. Das könntest du damit nachprüfen.

Werbeanzeige