Zustand eines Thread mit volatile BOOL variablen?

BorisDieKlinge

Hallo Leute,

ich hab nen thread welcher zyklisch daten liest, und welchen ich starten und stoppen kann. über ein Event steuer ich den thread.
Hier mal kurz der pseudecode.

BOOL boProgress=false;

Start(){ if(boProgress) return; SetEvent(EventPause); }
stop() { boProgress=false; ResetEvent)(EventPause);}
Thread(){
do{

  boProgress=false;
  WaitForSingleObject(EventPause,INFINITE);

  for(.....; ... boProgress ;....){
   ganz viele daten lesen
   //Datenlesen
  }
  Sleep(1000);

while(..);

}

Muss ich nun den BOOL wert boProgress volatile deklarieren? oder soll ich den "InProgress" meachnismus mit events machen?

Bei immer mehr überlegung köntne ich das ganzen events geschichte auch mit BOOL werten machen?

Start(){boWait=false;}
Stop(){boWait=true;}

Thread(){
do{

//Warten
  while(boWait);

  for(.....; ... boWait ;....){
   ganz viele daten lesen
   //Datenlesen
  }
  Sleep(1000);

while(..);

}

was spricht für BOOL voltaile bzw. für event und umgekehrt

Martin Richter

Hat nicht viel mit C++ zu tun und mehr mit WinAPI habe ich ds Gefühl...

1. volatile ist hier angesagt, sonst kan der Compiler die Variable evtl. wegoptimieren. Es darf hier auch nicht ein Register verwendet werden.
2. Ist nicht Dein ernst?

while(boWait);

Die Folge 100% Porzessorlast. Für nix! Genau hier benötigt man ein Event!
3. Events sind immer dann vorzuziehen, wenn man auf das Ereignis, warten muss. Flags sind genügend, wenn ein Zustand gemeldet werden soll, der sowieso zyklisch abgefragt werden soll. Zustände wie "Starten", "Hier ist Arbeit", "Beende" sind meistens Kandidaten für ein Event.

Ich hab im Forum schon öfter gelesen das man volatile nie braucht

BorisDieKlinge

Martin schrieb:

2. Ist nicht Dein ernst?

while(boWait);

upss... ^^ stimmte ja ne ..

das heist ein BOOl für inProgress ist schon ok!!! :schland:

camper

Martin Richter schrieb:

1. volatile ist hier angesagt, sonst kan der Compiler die Variable evtl. wegoptimieren. Es darf hier auch nicht ein Register verwendet werden.

Über Letzteres kann man u.U. streiten. Entscheidend ist aber, dass Zugriffe aus verschiedenen Threads auf dies Variable in irgendeiner Weise geordnet sein sollen und der Zustand des Objektes zwischen solchen Zuständen stabil ist. Genau das sichert volatile aber nicht zu - damit ist es für diesen Zweck ungeeignet. Natürlich können auf einer bestimmten Plattform zusätzlich Garantien gelten - das hat aber nichts mit Standard-C++ zu tun. Mithin ist dieser Thread hier völlig fehl am Platz, was dem OP bekannt sein musste. Werden umgekehrt Bibliotheksfunktion zur Synchronisation verwendet, wird volatile ebenfalls überflüssig, da diese Funktionen bereits dafür sorgen, dass das Objekt einen definierten Zustand entsprechend der abstrakten Semantik haben muss (sofern man irgendwie global darauf zugreifen kann).

Tachyon

Was ist BOOL?
Wieso benutzt Du nicht sowas wie boost::thread ?
Wenn Du schon mit WinAPI Threads hier ankommst, wieso stellst Du dann keine Fragen dazu, wie man das sinnvoll in wiederverwendbare Klassen kapseln kann? Das geht wunderbar.
Und was hat Deine Frage überhaupt mit C++ zu tun?

hustbaer

& schrieb:

Ich hab im Forum schon öfter gelesen das man volatile nie braucht

Wenn man korrekterweise Mutexen und deren implizite memory barriers verwendet braucht man volatile wirklich nicht.
Wenn man lustig rumhackt und nicht viel Schimmer hat braucht man volatile, damit man glaubt es richtig gemacht zu haben
(Und man *kann* volatile auch für einige Dinge verwenden die kein Blödsinn sind -- was allerdings plattformabhängig und nicht ganz trivial ist)

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum WinAPI verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.