ich möchte mich gerade mit Threads beschäftigen und wie Daten zwischen Thread sicher ausgetauscht werden können. Es geht hier um das lernen, also bitte die Fragen nach Sinn und Unsinn unter das Thema "Ja, kann man sicher auch anders lösen" stellen.

Ich möchte einen Zeiger auf ein Element von allen Threads und allen Klassen aus erreichbar machen. Dazu machen ich den Zeiger atomic. Und da ich gelesen habe, dass Zeiger in std::atomic am Besten in std::shared_ptr liegen, damit ein Thread den Zeiger nicht zerstärt, wärend ein anderer Thread diesen ggf. noch benutzt, versuche ich mich genau daran:

// Interface.h
class MyInterface abstract
{
public:
  virtual ~MyInterface() {};
  virtual void Run() = 0;
};

// Global.h
#include <atomic>
#include <memory>
#include <Interface.h>

extern std::atomic< std::shared_ptr< MyInterface > > iInterface;

// -----------------------
// Eins.h
#include <Interface.h>
#include <Global.h>

std::atomic< std::shared_ptr< MyInterface > > iInterface( nullptr );

class Eins : virtual public MyInterface
{
public:
  virtual ~Eins() {};
  void Run();
};

// Eins.cpp
#include <Eins.h>
#include <Zwei.h>

void Eins::Run() {};

int main(void)
{
  iInterface = std::shared_ptr< MyInterface >(new Eins());
  Zwei* MyDoIt(new Zwei());
  MyDoIt->DoIt(); // Das kommt später in einen Thread
  delete MyDoIt;
  MyDoIt = nullptr;
  return 0;
};

// -----------------------
// Zwei.h
#include <Interface.h>
#include <Global.h>

class Zwei
{
public:
  void DoIt();
};

// Zwei.cpp
#include <Zwei.h>
Zwei::DoIt()
{
  iInterface.load()->Run();
};

Wenn ich mal das ganze Atomic-Zeug raus mache, dann klappt das auch. Aber sobald ich std::atomic drinnen habe, erhalte ich nach Beendigung des Programmes die Fehlermeldung, dass auf bereits freigegebene Speicherbereiche erneut zugegriffen wird.

Deswegen habe ich den Debugger angeschmissen (VS 2013) und geschaut.
Wenn ich bei der Zeile "return 0;" in main() bin, dann hat mein shard_ptr einen "used" von 4294967295, also 1 unter NULL (underflow). Ich gehe davon aus, das dann versucht wird, den Pointer zu deleten und deswegen der Speicherzugriffs-Fehler entsteht.

Damit habe ich die Auswirkung. Was ich noch nicht habe, ist die Ursache. Wie und wo passiert es denn, dass der shared_ptr eine Benutzungsanzahl von kleiner 0 erhält?
Ich hab jetzt wirklich schon viel probiert und gedebugged, aber komme der Lösung nicht näher. Ich hab auch schon einiges gegoogelt, aber auch die Beiträge geben mir die Lösung nicht wirklich, wobei ich einige Beiträge gefunden habe, bei denen das gleiche Problem auftritt.

Man soll ja klare Fragen stellen:
Wie verwaltet man am Besten globale Zeiger, die in jedem Thread verfügbar sein sollen?

Danke,
Stefan

PS: Einige Fehler im Code ausgebessert.

Da du die vermutlich entscheidenden Dinge nicht gepostet hast, kann man zum Fehler hier nicht viel sagen.

Da du die vermutlich entscheidenden Dinge nicht gepostet hast, kann man zum Fehler hier nicht viel sagen.

Ich hab alles gepostet, wie es in meinem Test drinnen steht. Oder du sagst mir, was ich noch nicht gepostet habe, dann würde ich es ergänzen.

manni66 schrieb:

Globale Variablen werden nicht besser, bloß weil man mit Threads arbeitet. Ein shared_ptr als globale Variable dürfte wohl völlig sinnlos sein, der ist doch gerade zum Teilen da!

Ist ja auch ein LERNPROJEKT um mal mit atomic zu arbeiten und um die Threads- und Atomic-Denke im LIVE-Betrieb zu sehen!

Ich führe bei mir häufig eine recht starre Ordnung aus Hauptthread und Worker-Thread-pool ein, wobei der Haupthtread alle nicht-threadsafe-zugriffe erledigt und die Workerthreads die reinen Berechnungen.

manni66 schrieb:

Da du die vermutlich entscheidenden Dinge nicht gepostet hast, kann man zum Fehler hier nicht viel sagen.

Ich hab alles gepostet, wie es in meinem Test drinnen steht. Oder du sagst mir, was ich noch nicht gepostet habe, dann würde ich es ergänzen.

Der Code ist nicht übersetzbar. iInterface liegt im namespace ForAtomic, der wird aber bei der Verwendung nicht angegeben.

manni66 schrieb:

manni66 schrieb:

Globale Variablen werden nicht besser, bloß weil man mit Threads arbeitet. Ein shared_ptr als globale Variable dürfte wohl völlig sinnlos sein, der ist doch gerade zum Teilen da!

Ist ja auch ein LERNPROJEKT um mal mit atomic zu arbeiten und um die Threads- und Atomic-Denke im LIVE-Betrieb zu sehen!

Dann solltest du jetzt gelernt haben, das globale Variablen auch als atomic unbrauchbar und shared_ptr eben keine globalen Variablen sind.

stefanjann schrieb:

manni66 schrieb:

Globale Variablen werden nicht besser, bloß weil man mit Threads arbeitet. Ein shared_ptr als globale Variable dürfte wohl völlig sinnlos sein, der ist doch gerade zum Teilen da!

Ist ja auch ein LERNPROJEKT um mal mit atomic zu arbeiten und um die Threads- und Atomic-Denke im LIVE-Betrieb zu sehen!

Dann solltest du jetzt gelernt haben, das globale Variablen auch als atomic unbrauchbar und shared_ptr eben keine globalen Variablen sind.

Gut, jetzt weiß ich, wie es nicht geht. Hat noch jemand einen Wink in die richtige Richtung?

Mein Konzept:
Eine Klasse, die Atomic verschiedene Stati überwacht. (Bei mir Class Eins)
Viele Klassen, die in Threads laufen und Ihren Status übergeben. (Bei mir Class Zwei)

Die klare Frage:
Wo lege ich die Status-Klasse, wenn nicht in einem globalen namespace? Wie können die Threads darauf zugreifen?

Ausrede:
Die Idee mit der globalen Variablen im namespace kommt nicht von mir, die hab ich aus einem Tutorial. Ich nehme mal an, das Tut ist Mist?

PS:
Wäre denn mein Code richtig, wenn der atomic nicht global liegen würde? (Abgesehen, dass ich den namespace vor dem Interface jetzt versehentlich beim Copy & Paste vergessen habe....)

Mein Konzept:
Eine Klasse, die Atomic verschiedene Stati überwacht. (Bei mir Class Eins)
Viele Klassen, die in Threads laufen und Ihren Status übergeben. (Bei mir Class Zwei)

Die klare Frage:
Wo lege ich die Status-Klasse, wenn nicht in einem globalen namespace? Wie können die Threads darauf zugreifen?

Wenn du einen Status überwachen willst, hätte ich so etwas wie std::atomic<int> erwartet. Wo da ein Zusammenhang zu einem Interface mir einer Run-Methode ist, verstehe ich nicht.

Grunsätzlich ist der Sinn von atomic, dass zwei oder mehr Threads Änderungen auch "sehen", wenn sie in einem anderen Thread durchgeführt wurden. shared_ptr sorgen selber dafür, ein atomic ist dort nicht notwendig. Das betrifft aber natürlich nur den verwalteten Speicher (sprich den Pointer).

stefanjann schrieb:

PS:
Wäre denn mein Code richtig, wenn der atomic nicht global liegen würde? (Abgesehen, dass ich den namespace vor dem Interface jetzt versehentlich beim Copy & Paste vergessen habe....)

Dein Code lässt sich nicht übersetzen.
Fehler neben dem fehlenden Namespace:
- alle Methoden private
- delete auf Klassenname
Dann habe ich aufgehört.

Warum ist das Interface virtuell abgeleitet?

stefanjann schrieb:

Mein Konzept:
Eine Klasse, die Atomic verschiedene Stati überwacht. (Bei mir Class Eins)
Viele Klassen, die in Threads laufen und Ihren Status übergeben. (Bei mir Class Zwei)

Die klare Frage:
Wo lege ich die Status-Klasse, wenn nicht in einem globalen namespace? Wie können die Threads darauf zugreifen?

Wenn du einen Status überwachen willst, hätte ich so etwas wie std::atomic<int> erwartet. Wo da ein Zusammenhang zu einem Interface mir einer Run-Methode ist, verstehe ich nicht.

Grunsätzlich ist der Sinn von atomic, dass zwei oder mehr Threads Änderungen auch "sehen", wenn sie in einem anderen Thread durchgeführt wurden. shared_ptr sorgen selber dafür, ein atomic ist dort nicht notwendig. Das betrifft aber natürlich nur den verwalteten Speicher (sprich den Pointer).

manni66 schrieb:

Warum ist das Interface virtuell abgeleitet?

Stell dir folgendes vor:
Das Interface ist iLandkarte.
Abgeleitet davon werden cBayern, cHessen, etc...

Es gibt Klassen cAuto, cMotorrad, cAmpel, etc...

Aus iLandkarte kann ich mir die Koordinaten der Strassen abholen, auch die Verkehrsschilder um an einer Kreuzung die Vorfahrt zu regeln.
Mehrere Thread cAmpel laufen um an einigen Kreuzungen die Ampeln zu steuern und zu sagen, wer gerade Vorfahrt hat.

Es laufen mehrere Thread cAuto oder cMotorrad. (Geerbt von iFahrzeug).
Beim Start melden die sich bei iLandkarte an (registrieren sich) und übermitteln ihren aktuellen Status (z.B. Koordinaten, wo sich das Fahrzeug gerade befindet).
Alle iFahrzeug-Elemente sind beweglich müssen also die anderen Fahrzeuge abfragen (damit diese nicht zusammen krachen) und die Vorfahrtsregelungen aus den Verkehrsschildern und den Ampeln abfragen.

Dann bekommt jeder Fahrzeug-Thread einen Auftrag. Fahre von deiner aktuellen Position nach Position X,Y über die Strassen.

Dann starte ich noch eine Thread, der mir die Bildschirmausgabe macht (OpenGl oder DirectX, etc).

Jetzt die Fragen:
Wieso das Interface virtuell abgeleitet ist? Die Karte setzt sich später mal aus verschiedenen vererbten Klassen zusammen. Da ich dann eine Diamant-Vererbung erhalten werde, ist mein Interface virtuell. Das Interface selbst beinhaltet keine Funktionen, sondern nur "virtual = 0" und wird somit nur einmal benötigt.

manni66 schrieb:

Dein Code lässt sich nicht übersetzen.

Ja, sorry. Mit Copy und Paste zusammen geschustert und aus Faulheit nicht auf lauffähig geprüft. Gelobe Besserung beim nächsten Beispiel.

Lösungsansatz von mir
Ich habe irgendwo eine Variable mit extern definiert. Diese ist iLandkarte. Sobald alles wichtige verarbeitet ist (Icons laden, etc) wird irgendwoher die Entscheidung errechnet, welche Landkarte (cBayern, cHessen) geladen wird.
Ich starte alle Thread, die mir die Landkarte auferlegt (cAmpel, etc)
Ich starte ein Fahrzeug nach dem anderen in einem Thread und gebe gleich ein Ziel an.
In jedem Thread muss ich irgendwie auf die Landkarte zugreifen und auch alle Änderungen sofort mitbekommen, weil sich ja alle Fahrzeuge bewegen (außer die stehen an der Ampel) und auch die Ampeln nur zu bestimmten Zeiten auf Grün sind. Das mache ich über die (bei mir noch) globale Variable.
Die Bildschirmausgabe fragt alle die Landkarte ab, die Ampeln und alle Fahrzeuge und zeichnet dann was schönes.

Und jetzt?
...hoffe ich, jemand sagt mir, wie man das richtig plant und gibt mir vielleicht ein Schema, wie meine Klassen angelegt werden müssten.

Danke.

std::atomic<> macht erstmal nur Sinn für eine Handvoll Typen für die es spezialisiert ist (die vollständige Liste findest du z.b. hier). Es gibt dann noch eine Handvoll Sonderregeln für POD-Typen, aber das trifft alles nicht auf deinen shared_ptr zu.

Was du brauchst sind die freien atomic Funktionen für shared_ptr. Wie bei allem was in C++ atomic im Namen hat sind die aber nicht ganz einfach zu verwenden.

Beachte dass im shared_ptr der Reference Count schon von Haus aus thread-safe ist. Solange du also wirklich nur die Referenz auf ein Objekt zwischen verschiedenen Threads teilen willst (also verschiedene shared_ptr Objekte die auf das selbe Objekt zeigen und sich einen Refcount teilen) klappt das von Haus aus ohne große Luftsprünge. Erst wenn du ein einzelnes shared_ptr Objekt zwischen Threads teilen willst wirds knifflig. Dieser Anwendungsfall taucht aber im wirklichen Leben zum Glück nur höchst selten auf.

...

Danke,
dann werde ich mich da nochmal etwas durcharbeiten...