Threadgestaltung bei erwünschtem Abbruch

hustbaer

Michael E. schrieb:

Ich meinte, wie du dem Worker Thread mitteilst, dass er seine aktuelle Berechnung abbrechen und sich die neuen Parameter anschauen soll.

Naja, Beispiel:

TaskHandle h = queue.QueueTask(work);
h.Cancel();

OK, "work" muss das nun noch irgendwie mitbekommen. Wie man das implementiert, hängt nun davon ab, was QueueTask() als Parameter nimmt - also was "work" für nen Typ haben darf.
Wenn man super-generisch sein will, und QueueTask() nen std::function<void()> frisst, dann wird's ein wenig kompliziert. Dann muss man wohl oder übel mit Thread-Local-Storage arbeiten.

Wenn man dagegen einfach verlangt, dass jeder Task ("work") eine Schnittstelle ITask implementiert, dann kann diese ja z.B. einfach so aussehen:

class ITask
{
public:
    // ...
    virtual void Run() = 0;
    virtual void Cancel() = 0;
};

Der Task wiederum kann das dann machen wie er möchte, ein atomic cancel-flag verwenden, bool + Mutex, was auch immer (oder den Cancel() Aufruf gleich ganz ignorieren).

Michael E.

Ah, ich dachte, da gibts dann irgend nen tollen Trick mit einer Condition Variable, den ich nicht kenne.

dot

Achso nein, die CV war nur gedacht zum Schlafen auf der Queue

314159265358979

@dot: Warum volatile? Wolltest du nicht atomic<bool> sagen?

hustbaer

Für ein Cancel-Flag reicht volatile mMn. aus.

Es muss ja nicht sofort vom anderen Thread "gesehen" werden, und das Lesen/Schreiben muss normalerweise auch keine Memory-Order implizieren.
Zumindest so lange man die Information "canceled" nicht mit irgendwas anderes verknüpft.
Es reicht also, wenn wir sicherstellen, dass der Lese-/Schreibvorgang nicht komplett wegoptimiert wird. Und genau dafür ist volatile gut, wenn ich mich recht erinnere.

Wenn der gecancelte Task natürlich im "if (Canceled())" irgendwas macht, was sich darauf verlässt dass bestimmte Dinge jetzt so-und-so sein müssen, weil "sonst wäre ich ja nicht gecanceled worden", dann wäre das natürlich böse.
Ein Programm dass solche Abhängigkeiten enthält, würde ich aber schon mal grundsätzlich als problematisch bezeichnen, d.h. die Restriction dass man sowas eben nicht machen darf, halte ich für nicht sehr schlimm.

Und da ein volatile Read/Write auf vielen Plattformen um Grössenordnungen billiger ist als ein atomic Read/Write...

(Man vergebe mir das schlimme Denglisch in diesem Beitrag, aber es schert mich jetzt nicht das nochmal umzuschreiben *g*)

dot

Nö ich meinte schon volatile, warum müsste der denn deiner Meinung nach atomic sein?

EDIT: Genau was hustbaer sagt

314159265358979

Warum habt ihr dann damals bei meinem (zugegebenermaßen hässlichen) IRC-Server so heftig protestiert?

dot

Vermutlich weil volatile dort eben nicht ausreichend war? Manche Leute verwechseln volatile gern mit "threadsafe"...

hustbaer

Weiss ich nimmer, dazu müsstest du den Thread rauskramen
Idealerweise einfach nen Link posten, dann können wir dort weiterdiskutieren um diesen Thread nicht noch mehr zuzumüllen.

314159265358979

Den Thread find ich wohl nicht mehr. Ich weiß nur noch, dass mein Code in etwa so aussah:

volatile bool run = true;

void do_server_stuff()
{
    while(run)
       do_stuff;
}

void exit_server()
{
    run = false;
}

dot

Das ist ok.

hustbaer

Naja, das alleine sieht harmlos aus.
Aber wie gesagt, ich kann mich nimmer erinnern.

314159265358979

Thread gefunden. www.c-plusplus.net/forum/p2104471#2104471
Überlest einfach mal, was da sonst so steht. Ist ja peinlich.

hustbaer

Auch das was in dem Thread sieht für mich OK aus. Tjoah... Threads sind halt so ein Thema was kaum wer wirklich versteht. Auch ich würde mein Leben nicht darauf verwetten dass alles so 100% stimmt wie ich es meine verstanden zu haben. Ich bin mir bloss seeeehr sicher, aber was heisst das schon
Es findet sich sicher auch jmd. der das was in diesem Thread geschrieben wurde für Unfug hält

314159265358979 schrieb:

Thread gefunden. www.c-plusplus.net/forum/p2104471#2104471
Überlest einfach mal, was da sonst so steht. Ist ja peinlich.

Die Diskussion zu volatile drehte sich nicht darum, dass volatile hier nicht geht, sondern darum, dass deine Auffassung, was volatile macht, falsch war, dass du dir dadurch Performancezuwachs erhofft hast, ohne wirklich zu messen, was andere (evtl. bessere) Lösungen in dem Fall kostet (pauschal "0,5ms" angeben ist bestenfalls Mutmaßung), und dadurch dein Server unnötig rödelt.

Lt Standard, ist volatile ein Hinweis (!) für den Compiler, agressive Optimierung zu vermeiden. Ansonsten soll es sich genau so verhalten, wie es im C-Standard definiert ist. Und dort steht:

A volatile declaration may be used to describe an object corresponding to a memory-mapped
input/output port or an object accessed by an asynchronously interrupting function. Actions on
objects so declared shall not be ‘‘optimized out’’ by an implementation or reordered except as
permitted by the rules for evaluating expressions.

Ich verstehe das so, dass ein Zugriff auf ein mit volatile spezifiziertem Element nicht vor die vor im stehenden Zugriffe reordered werden darf, und dass das Element im Speicher vorhanden sein muss (es also nicht komplett wegoptimiert werden darf).

Damit ist es nicht atomar (was bei bool aber keinen Unterschied machen sollte).

Wann exakt andere Threads eine Änderung an einem volatile sehen ist damit nicht vorhersagbar, sondern hängt vom Rest des Programms, sowie der verwendeten Maschine ab.

Ist das so in etwas richtig?

Eisflamme

Hi,

danke für die zahlreichen Antworten! Ich habe mir alles durchgelesen und bin nun erfreut, dass mein Verständnis sich verbessert hat. Warum der Zähler über die Leitplanke springt, weiß ich immer noch nicht, denn die eigentliche Zeile ist:
for(std::size_t pos = 0; pos < 2598960; ++pos)
und er dumpt damit, dass die Arraygrenzen bei pos = 2598960 überschritten sind, aber das analysier ich lieber, wenn ich den Rest umgebaut hab.

Threads sind halt so ein Thema was kaum wer wirklich versteht.

Oh, danke! Ich dachte, ich würde irgendwo hinterm Mond leben. Ich programmier ja mittlerweile auch ein kleines Weilchen und hatte nie mit Threads zu tun (bedauerlich, ja). Jetzt bastel ich bei dem UI-Zeug damit rum und merke, dass das ein ganz neues Thema ist. Fühle mich wie ein kleines Kind.

Auch mit atomic... Wert wird in Register geschrieben, inkrementiert und zurückgeschrieben... ich hätte jetzt einfach ein rohes bool genommen *schäm*
Edit: Ok, was ja volatile auch reicht. Aber ist diese Definition eigentlich erzwingend? Wenn das nur eine "Recommendation" für den Compiler ist, dann könnte er es ja auch ignorieren. Das jedoch wäre fatal.

Irgendwie braucht man für MT echt das Wissen, wie jedes kleine Detail abläuft. Das braucht man sonst oft nicht.

dot

volatile schrieb:

Ich verstehe das so, dass ein Zugriff auf ein mit volatile spezifiziertem Element nicht vor die vor im stehenden Zugriffe reordered werden darf, und dass das Element im Speicher vorhanden sein muss (es also nicht komplett wegoptimiert werden darf).

Hängt von der Art des Zugriffes aber, aber im Prinzip: Ja.

volatile schrieb:

Damit ist es nicht atomar (was bei bool aber keinen Unterschied machen sollte).

Natürlich ist es nicht atomar. Was meinst du mit "keinen Unterschied machen"?

volatile schrieb:

Wann exakt andere Threads eine Änderung an einem volatile sehen ist damit nicht vorhersagbar, sondern hängt vom Rest des Programms, sowie der verwendeten Maschine ab.

Das wäre mit Atomics doch auch nicht anders!?

Nö ich meinte schon volatile, warum müsste der denn deiner Meinung nach atomic sein?

Hans Böhm empfiehlt bei C++11 auf jeden Fall std::atomic statt volatile zu verwenden.
http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/user-faq.html#ordered

Und auch Anthony Williams implementiert in seinem Buch das interrupt_flag als:

std::atomic<bool> flag;

http://www.amazon.com/C-Concurrency-Action-Practical-Multithreading/dp/1933988770

Um Data Races zu vermeiden, sollte std::atomic statt volatile verwendet werden.

dot

Es gibt dort aber keine Data Race und ich sehe nicht was ein Atomic dort bringen würde...