ich habe in letzter Zeit immer wieder das Problem, dass ich eine Klasse mit bestimmter Funktionalität in einem eigenen (background thread) arbeiten lasse bis diese fertig ist oder unterbrochen wird.

Das Problem dabei ist, dass die Klasse oft so designed wurde, dass sie von dieser unterbrechnungs-Funktionalität nichts weiß.

Zum Beispiel ein Lexer: Der könnte ja erstmal (vereinfacht) so aussehen (in Anlehung an das Tutorial hier):

class lexer
{
    std::string input;
    size_t pos;
    char last_char;
public:
    lexer(std::string const &input);
    token get_next();
    bool finished() const;
};

Soweit so gut, das geht auch alles. Jetzt will ich eine teure Operation (also zum Beispiel das lexen eines langen Texts) in einem Hintergrund-Thread erledigen und das Ganze unterbrechbar machen. Also etwa so:

lexer lex("irgendein langer Text");

while (!lex.finished())
{
    auto t = lex.get_next(); // Hole nächstes token
    if (thread_should_stop()) // Überprüfen ob thread unterbrochen werden soll
    {
        break; // Abbruch, thread wird beendet
    }
}

Auch das klappt wie gewünscht und problemlos. Hier kümmert sich die thread Funktion um den Abbruch und der Lexer selbst muss davon nichts wissen. So wie es sein soll.

Mein Problem ist jetzt, dass etwa die get_next Methode sehr lange brauchen kann wenn das token extrem lang ist (mehrere Sekunden). Das ist insofern blöd, dass der Abbruch dann nicht sofort passiert sondern erst nach einer merklichen Wartezeit.

Um das zu vermeiden müsste ich aber die Abbruchbedingung direkt in den lexer implementieren, der ja generisch sein soll und eigentlich nichts davon weiß ob er in einem eingenen thread läuft oder nicht - ein Widerspruch?

Wie könnte man das Problem am besten lösen? Muss man die allgemeingültigkeit des Lexers aufgeben oder gibt es eine bessere Lösung?

Für Funktionen gilt, was du gesagt hast: sie können eine Bedingung prüfen und sich gegebenenfalls beenden. Bei verschachtelten Funktionen ist dann natürlich die Frage, wie der Aufrufer darauf reagieren soll.

Dein Lexer muss also darauf vorbereitet sein, er muss aber nicht wissen, ob er in einem separaten Thread herausgeführt wird.

Da Klassen niemals ausgeführt werden, kann man sie auch nicht unterbrechen.

Schon klar, das meinte ich ja

manni66 schrieb:

Dein Lexer muss also darauf vorbereitet sein, er muss aber nicht wissen, ob er in einem separaten Thread herausgeführt wird.

Ja, aber wie?

Ich muss ja irgendwo in get_next dann entsprechen thread_should_stop aufrufen - welches eine member Funktion meiner worker Klasse ist. Um auf dieses Zugriff zu haben müsste der lexer aber eine Referenz auf diese worker Klasse speichern. Also würde er "wissen" dass er in einem eigenen thread ausgeführt wird.

Zum Thema:

Ich würde dem Lexer ein eigenes Flag "lexer_should_stop" geben. Das kannst du dann auf false setzen, wenn der Worker beendet werden soll. Dann weiß der Lexer nichts darüber, dass er in einem eigenen Thread läuft oder was ein Worker ist, bietet aber trotzdem die Möglichkeit, über irgend einen Mechanismus beendet zu werden. Um so ein Flag kommst du ja nicht rum - der Lexer muss ja wissen, dass er die Ausführung beenden soll.

Ist dir schon mal aufgefallen, dass man das Wort "Unterbrecher" nicht ohne "Erbrecher" schreiben kann?

Ja. Und?

Unterbrecher schrieb:

Zum Thema:

Ich würde dem Lexer ein eigenes Flag "lexer_should_stop" geben. Das kannst du dann auf false setzen, wenn der Worker beendet werden soll. Dann weiß der Lexer nichts darüber, dass er in einem eigenen Thread läuft oder was ein Worker ist, bietet aber trotzdem die Möglichkeit, über irgend einen Mechanismus beendet zu werden. Um so ein Flag kommst du ja nicht rum - der Lexer muss ja wissen, dass er die Ausführung beenden soll.

Wie soll das mit einem flag im lexer gehen?? Der lexer wird doch nicht von außerhalb geprüft ob gestoppt werden soll, sondern er muss das selbst überprüfen. Das relevante flag befindet sich schließlich in der worker Klasse.

Ich muss ja irgendwo in get_next dann entsprechen thread_should_stop aufrufen - welches eine member Funktion meiner worker Klasse ist. Um auf dieses Zugriff zu haben müsste der lexer aber eine Referenz auf diese worker Klasse speichern. Also würde er "wissen" dass er in einem eigenen thread ausgeführt wird.

Wenn du bei jeder Antwort flugs ein paar neue Bedingungen nachlegst, wirst du nicht weit kommen.

class lexer
{
...
    std::atomic<bool> abort_function = false;

    token get_next()
    {
       if(abort_function) // hier beenden
    }
};

Wer auch immer entscheidet, dass der Thread zu beenden ist, muss abort_function auf true setzen.

Wer auch immer entscheidet, dass der Thread zu beenden ist, muss abort_function auf true setzen.

Hm ja, das meinte ich. Also ich komme wohl nicht darum rum das in irgendeiner Form direkt im lexer zu implementieren... Na gut, dann muss ichs wohl so machen^^

Kellerautomat schrieb:

Wenn dein Lexer so langsam ist, hast du andere Probleme...

Wie kannst du das beurteilen ohne überhaupt den input zu kennen? Ab einer bestimmten Größe geht jeder lexer mal in die Knie

Die Implementierung ist ziemlich genau nach dem oben verlinkten tutorial gemacht, dachte eigentlich da das von dieser Seite hier kommt ist die auch ziemlich gut...

Unterbrecher schrieb:

Ist dir schon mal aufgefallen, dass man das Wort "Unterbrecher" nicht ohne "Erbrecher" schreiben kann?

Ja. Und?

Nichts weiter.

happystudent schrieb:

Wie soll das mit einem flag im lexer gehen?? Der lexer wird doch nicht von außerhalb geprüft ob gestoppt werden soll, sondern er muss das selbst überprüfen. Das relevante flag befindet sich schließlich in der worker Klasse.

Du setzt das Flag von außerhalb über eine Methode des Lexers und dieser prüft intern das Flag. Woher soll er sonst wissen, dass er beendet werden soll?

enum class input_status
{
	success,
	end,
	cancelled
};

struct input_element
{
	input_status status;
	char value_if_success;
};

struct input
{
	virtual ~input();
	virtual input_element get_next() = 0;
};

struct lexer
{
	explicit lexer(input &in);
};

Der hässliche Multi-Threading-Teil kommt in eine separate Klasse. Um mit dem Atomic nicht zu viel Zeit zu verschwenden, habe ich einen Optimierungsversuch unternommen. Ob das auf deiner Hardware unter deinem Workload relevant ist, weiß ich natürlich nicht.

struct cancellable_input : input
{
	explicit cancellable_input(boost::iterator_range<char const *> remaining)
		: remaining(remaining)
	{
	}

	virtual input_element get_next() override
	{
		size_t const cancellation_latency = 1000;
		if (remaining.size() % cancellation_latency == 0)
		{
			//Es könnte unter Umständen sehr teuer sein ständig atomar zu lesen.
			//Deswegen wird das hier im Beispiel nur jeweils nach ${cancellation_latency} Elementen gemacht.
			if (cancelled)
			{
				return input_element{input_status::cancelled, 0};
			}
		}
		if (remaining.empty())
		{
			return input_element{input_status::end, 0};
		}
		char c = remaining.front();
		remaining.pop_front();
		return input_element{input_status::success, c};
	}

	void cancel()
	{
		cancelled = true;
	}

private:

	boost::iterator_range<char const *> remaining;
	std::atomic<bool> cancelled;
};

----

Die hier gestellte Frage ist mit C++ mMn. grundsätzlich unlösbar. Wenn man Funktionen unterbrechbar machen möchte, dann muss man sie halt unterbrechbar machen. Automagisch geht da nix.
Die einfachste Variante das zu machen ist wohl ein atomic<bool> cancelFlag .

struct lexer
{
    token get_next(std::atomic<bool> const &abort_function)
    {
		while ...
		{
			if(abort_function) // hier beenden
		}
    }
};

Die Referenz kann man beliebig tief weitergeben und so oft prüfen, wie nötig.

hustbaer schrieb:

Oder wenn man sinnvollerweise nicht eine virtuelle Funktion pro Zeichen aufrufen mag.

Weil virtuelle Methoden ja so teuer sind und es keine Templates gibt.

hustbaer schrieb:

Oder wenn man sinnvollerweise nicht eine virtuelle Funktion pro Zeichen aufrufen mag.

Weil virtuelle Methoden ja so teuer sind und es keine Templates gibt.

Ja, Templates zu verwenden wäre eine Möglichkeit. Du hast es halt mit virtuellen Funktionen gezeigt. Und ja, bei einem Lexer pro char eine virtuelle Funktion aufrufen ist teuer. Kannst es ja mal ausprobieren wenn du meinst dass der Unterschied nicht signifikant wäre.