Meine Thread Klasse (bitte mal testen)

*D*Evil

Kennst du std::queue? Wäre was für dich ^^

if(mThread)
            delete mThread;

oft gesehen und dennoch überflüssig:

delete mThread;

und fertig delete 0 führt zu keinem Fehler ... usw. also da kann man einiges optimieren

Simon2

Plassy schrieb:

...Ich habe Das jetzt so implementiert, dass es ohne mutexes und system-lock Aufrufe auskommt...

Das wird lustig !

Gruß,

Simon2.

Plassy

(D)Evil schrieb:

Kennst du std::queue? Wäre was für dich ^^
if(mThread)
            delete mThread;
oft gesehen und dennoch überflüssig:
delete mThread;
und fertig delete 0 führt zu keinem Fehler ... usw. also da kann man einiges optimieren

zu std::queue:
hab ich auch schon dran gedacht. Meiner meinung nach war das problem aber zu simpel um einen stl-container reinzustopfen. Aber gut, das könnte ich natürlich noch ändern.

zu delete 0:
Huh?? Hab ich nicht gewusst

Plassy

Simon2 schrieb:

Plassy schrieb:

...Ich habe Das jetzt so implementiert, dass es ohne mutexes und system-lock Aufrufe auskommt...

Das wird lustig !

Gruß,

Simon2.

Deswegen ist es ja auch in einer Klasse gekapselt.

BorisDieKlinge

Ich würde mich nie Trauen ne Klasse von mir hier rein stellen;) Nach der kritik schieb man nur noch depries

hustbaer

Kann den Thread bitte wer löschen damit nicht noch irgendwer auf die Idee kommt den greislichen Horror da oben zu verwenden?

Plassy

@hustaer

Plassy schrieb:

...oder ein paar Kommentare (konstruktive ;)) zu dem Design abgeben könnte.

hustbaer

Was willst du von mir? Du setzt dich über sämtliche Regeln zum Thema Threading hinweg weil du dich in deiner unendlichen Selbstüberschätzung für reichlich schlau hältst, und postest gemeingefährlich falschen Code. Glaubst du nicht wenn es so einfach ginge wäre da vor dir schon jemand draufgekommen? Ja, wäre, und nein, so einfach geht es nicht.

Konstruktive Kritik: die ganzen "volatile bool" sind alle Blödsinn, das funktioniert so nicht, das führt nur zu bösen race conditions (aka. data races) und im endeffekt dazu dass das ding irgendwann abstürzt oder sonstwie gröber Blödsinn baut.

inline unsigned int getNumTasks() const
    {
        while(not mIsAllowedToQueue)
            /* waiting */;

        return mNumTasksQueued - mNumTasksRemoved;
    }

solange er nicht die erlaubnis zum queuen hat gibt er was zurück. und was macht er sonst?

wieso ist eigentlixch not blau. mein VS 2003 kennt kein not.

ich sehs. ein ; hinter dem kommentar.

hustbaer

not ist auch kein Keyword sondern ein define:

#define not !

Sollte sich in <iso646.h> befinden.

camper

hustbaer schrieb:

not ist auch kein Keyword sondern ein define:
#define not !
Sollte sich in <iso646.h> befinden.

not ist ein keyword - Visual C++ hält sich in diesem Punkt nur nicht an den Standard. Es ist in keinem Falle eine schlechte Idee, <ciso646> einzubinden für den Fall der Fälle.

Plassy

hustbaer schrieb:

Was willst du von mir? Du setzt dich über sämtliche Regeln zum Thema Threading hinweg weil du dich in deiner unendlichen Selbstüberschätzung für reichlich schlau hältst, und postest gemeingefährlich falschen Code. Glaubst du nicht wenn es so einfach ginge wäre da vor dir schon jemand draufgekommen? Ja, wäre, und nein, so einfach geht es nicht.

lol du bist ja ein fröhlicher Geselle.

hustbaer schrieb:

Konstruktive Kritik: die ganzen "volatile bool" sind alle Blödsinn, das funktioniert so nicht, das führt nur zu bösen race conditions (aka. data races) und im endeffekt dazu dass das ding irgendwann abstürzt oder sonstwie gröber Blödsinn baut.

Aber trotzdm würde ich doch gerne etwas näher wissen warum das jetzt in diesem fall zu race-conditions führen kann.
Die ganzen bools waren eigendlich dazu gedacht Das zu verhindern.
In wie fern funktioniert Das jetzt nicht??

MfG
Plassy

Plassy schrieb:

Aber trotzdm würde ich doch gerne etwas näher wissen warum das jetzt in diesem fall zu race-conditions führen kann.
Die ganzen bools waren eigendlich dazu gedacht Das zu verhindern.
In wie fern funktioniert Das jetzt nicht??

Wärend einer der bool Variablen verändert wird, kann ein Threadwechsel auftreten. Dann der Wert in der Boolvariable undefiniert.

Außderdem. Wer sagt dir, dass nachdem du eine dieser while-Schleifen verlassen hast, nicht direkt der Threadwechsel statt findet. Dann laufen plözlich 2 Threads gleichzeitig.

So eine Klasse kann man in der Praxis gar nicht gebrauchen.

Plassy

ProgChild schrieb:

Wärend einer der bool Variablen verändert wird, kann ein Threadwechsel auftreten. Dann der Wert in der Boolvariable undefiniert.

Außderdem. Wer sagt dir, dass nachdem du eine dieser while-Schleifen verlassen hast, nicht direkt der Threadwechsel statt findet. Dann laufen plözlich 2 Threads gleichzeitig.

Danke :D. Das ist doch mal ne konstruktive antwort
Aber die Werte der bool variablen dürften doch eigendlich nie undefiniert sein.
Wenn ein thread die Variable schreibt und der andere thread die Variable liest bevor der erste thread zuende geschrieben hat, wäre das doch eigendlich völlig egal da ja nicht der genaue Wert abgefragt wird. Es wird ja nur abgefragt ob die Variable 0 oder nicht 0 ist. Ob am ende irgend ein Datenmüll drin steht dürfte dann doch egal sein, da es nicht 0 und somit "true" wäre. Oder gibts in diesen Fall noch was dazwischen?

Dein zweites Argument verstehe ich leider nicht so richtig.
Kannst du das vielleicht noch mal irgendwie anders formullieren?

MfG
Plassy

Plassy

nutzlos schrieb:

So eine Klasse kann man in der Praxis gar nicht gebrauchen.

Und wieso nicht...??
Ist Das jetzt auf die Funktion bezogen oder auf die Umsetzung?

Werner Salomon

Plassy schrieb:

nutzlos schrieb:

So eine Klasse kann man in der Praxis gar nicht gebrauchen.

Und wieso nicht...??
Ist Das jetzt auf die Funktion bezogen oder auf die Umsetzung?

Hallo Plassy,

Eine race-condition kann genau dann auftreten, wenn einer der Thread unmittelbar hinter der Schleife

while(not mIsAllowedToQueue) // bzw. while(mIsQueuing)
            /* waiting */;

unterbrochen wird und der andere Thread jetzt weiterläuft. Das Flag, was Die Sperrung des Bereichs markiert - also entweder 'mIsQueuing' bzw. 'mIsAllowedToQueue' - ist dann noch nicht gesetzt. Dann rennt der zweite Thread in den anscheinend geschützten Bereich, wird womöglich selber unterbrochen, dann kommt wieder der andere dran .. und die race-condition ist da.

.. es gibt noch einen Grund. Das betrifft die Art und Weise, wie Du wartest. Du tust das in der schon erwähnten Schleife, die lediglich auf die Änderung eines bool-Wertes reagiert. Das klappt i.A. wenn Dein Programm mit den zwei Threads das einzige - oder fast das einzige - auf dem Rechner ist. Wenn Du das Verfahren in mehr als einem Thread machst und/oder die CPU-Last hoch geht, dann kann es schon passieren, dass Deine CPU sich zu mehreren 10% nur noch in diesen Schleifen tollt. Auf die Performance des Gesamtsystems wirkt sich das furchtbar aus.

Schau Dir vielleicht mal dies hier an. Ich verwende da zwar nur einen int-Wert als Kommando aber grundsätzlich könnte man den Kommando-Typ auch durch ein boost::function<void> ersetzen. Dann wäre man völlig flexibel.

Gruß
Werner

Bashar

ProgChild schrieb:

Wärend einer der bool Variablen verändert wird, kann ein Threadwechsel auftreten. Dann der Wert in der Boolvariable undefiniert.

Aber nur theoretisch. Ein bool ist ein Byte, das schreibt man in einer Instruktion, da kann also kein Threadwechsel dazwischenfunken.

Plassy

@Werner Salomon

Hey danke, Das sieht wirklich gut aus.
Ich habe noch eine zweite Version der Klasse die ich auch mit nem mutex schütze.
Aber dein code wirkt doch etwas edler ;).
Ich werde mich dann wohl an dein Beispiel halten.

Was mich aber auf die Idee gebracht hat das ohne system-lock Befehle
zu realisieren war dieser Artikel:

Lock-free Interprocess Communication
http://www.ddj.com/cpp/189401457

Ich habe das Prinzip dann so abgeändert, dass es zu meinem Problem passt.
Aber vielleicht habe ich auch was falsch verstanden??

Noch was zu deiner Klasse...

// -- Members
boost::mutex m_guard;
boost::condition m_signal;
std::queue< Cmd > m_input;
boost::thread m_thrd;       // MUSS hier letztes Member sein!

Wiso muss "m_thrd" der letzte member sein??
Und danke nochmal .

MfG
Plassy