folgende Situation: ich habe einen Main-Thread, in dem via non-blocking Sockets Daten ankommen. Ich verarbeite diese nun vorab und bereite diese auf.

Nun soll ein Thread erstellt werden, der die Daten annimmt (diese Daten bestehen aus einer simplen Klasse mit einer std::map<std::string, std::string> und std::vector<char>). Der Thread stellt dann was mit den Daten an und erstellt ein neues Datenpaket daraus. So weit kein Problem.

Das eigentliche Problem ist nun, dass aus dem Thread aus eine Funktion im Haupt-Thread aufgerufen werden muss - also ein cross-thread call (die neuen Daten sollen dabei übergeben werden). Das knifflige: Der Haupt-Thread darf unter keinen umständen pausiert werden. Das wiederrum tolle an der Sache: es muss niemals ein zweiseitiger Zugriff stattfinden (ergo kann ich mir Mutexing meiner Meinung nach sparen). Leider finde ich unter diesem Suchbegriff fast nichts. Woran liegt das? Ist die Methode so unüblich?

Ich kenne diese Vorgehensweise aus C# und dort funktioniert sie ganz wunderbar einfach.

Wonach muss ich suchen?
Oder gibt es bessere Verfahren für mein Problem?
Ich bitte darum, von Lösungen mit boost oder anderen externen Bibliotheken abzusehen. (ja, ich weiß, dass es eine quasi-standard-Bibliothek ist)

Das eigentliche Problem ist nun, dass aus dem Thread aus eine Funktion im Haupt-Thread aufgerufen werden muss - also ein cross-thread call (die neuen Daten sollen dabei übergeben werden). Das knifflige: Der Haupt-Thread darf unter keinen umständen pausiert werden.

Eine Funktion gehört nicht zu irgendeinem Thread. Das einzige Problem bei Einsatz von Threads ist Synchronisation, wenn Du das - wie auch immer - nicht hast, dann hast Du keins.

Genau das darf aber nicht. Die aufgerufene Funktion muss wieder im Kontext des Haupt-Threads laufen, da es Daten durch das Socket verschicken muss und generell vorher noch einige Operationen laufen lässst.

Demnach gibt es wohl doch Synchronisationsbedarf. Das Problem ist nur, dass bei Synchronisierung immer ein Thread warten muss. Und das darf bei mir eben nicht der Haupt-Thread sein...

Diese Methode ist nicht unüblich. Einerseits kannst Du das direkt mit (OS) API Funktionen erreichen (unter Windows z.B. PostThreadMessage(..) oder QueueUserAPC(..)) oder z.B. mit boost::asio realisieren (z.B. einen boost::asio::io_service mit nur einem Thread betreiben und dann boost::asio::io_service::post(..) benutzen.). Die Problematik liegt allerdings darin, dass es viele Mechanismen für Event-Loops/Dispatcher gibt () und diese untereinander nicht kompatibel sind.

Z.B. muss für User APC der Thread im alertable Zustand sein, was durch einen Aufruf von z.B. SleepEx(..) erreicht wird. Das heisst, wenn Du einen Windows Message Loop hast, kommst Du mit z.B. boost::asio nicht weit, dafür mit PostThreadMessage(..).

Moment... Wenn ich aus dem Worker-Thread heraus eine Funktion aufrufe, befindet sich die aufgerufene Funktion doch nun auch im Kontext des aufrufenden Threads, oder nicht? (Da bin ich mir eigentlich relativ sicher)

Selbstverständlich ist das so.
Um eine Funktion an einen anderen Thread weiterzugeben, hinterlegt man diese an einem gemeinsam bekannten Ort von dem der andere Thread sich die abholt und ausführt ( boost::asio::io_service::post()/run() ). In .NET nennt man das Dispatcher .

theliquidwave schrieb:

Genau das darf aber nicht. Die aufgerufene Funktion muss wieder im Kontext des Haupt-Threads laufen, da es Daten durch das Socket verschicken muss und generell vorher noch einige Operationen laufen lässst.

Warum verschickt das nicht einfach der Worker oder ein ganz anderer Thread? Was genau ist der Zweck des Haupt-Threads? Was für "Operationen" finden da noch statt?

Du musst konkreter werden. Multi-Threading ist nicht einfach und es gibt keine Patentrezepte.
Am besten lernst du erst einmal selbst wie das mit Threads funktioniert (zum Beispiel mit Boost.Thread). Die Antworten hier dürften hingegen eher für Verwirrung sorgen.

Wenn es keine begründeten Argumente gegen Boost.Asio gibt, nimm besser das für Netzwerk und als Dispatcher.

[Momentan im HauptThread]
                |
		    |
		    |
		    v
Daten kommen via Socket an (recv)
                |
		    |
		    |
		    v
Werden aufbereitet in eine Klasse:

class Data
{
public:
	// Getter & Setter

private:
	std::map<std::string, std::string> _pairs;
	std::vector<unsigned char> _bytes;
};
                |
		    |
		    |
		    v
Daten werden weiterhin im Haupt-Thread verarbeitet
                |
		    |
		    |
		    v
Haupt-Thread ruft neuen Thread (Worker Thread) und übergibt
Daten via Pointer (vllt. geht das auch über RAII?)
                |
		    |
		    |
		    v
Haupt-Thread soll weiterhin ohne geblockt zu werden laufen,
greift nicht auf die Daten zu.
Worker-Thread greift auf Daten zu und verarbeitet diese.
                |
		    |
		    |
		    v
Worker-Thread ist fertig mit verarbeiten und muss nun wieder
eine Funktion im Haupt-Thread aufrufen ("dispatchen"), Worker-Thread kann sterben
                |
		    |
		    |
		    v
Aufgerufene Funktion muss im Haupt-Thread aufgerufen werden,
verarbeitet neu erstellte Daten aus dem Worker-Thread, die übergeben werden sollten
                |
		    |
		    |
		    v
Funktion unter Haupt-Thread versendet neue Daten via Socket (send)

Der Main-Thread liest SCGI Requests vom Webserver und erzeugt die Worker-Threads (bzw. verteilt die Requests an gepoolte Worker-Threads - was auch immer).
Die Worker-Threads bauen aus den Requests Antworten und stecken sie in die Antwort-Queue.
Und der Antwort-Schreibe-Thread nimmt die Antworten aus der Antwort-Queue und schickt sie zurück an den Webserver.

Die Queue implementierst du klassisch mit den Funktionen der Threading-API die du verwendest, also mit z.B. Mutex + Condition-Variable, Critical-Section + Event oder was du halt zur Verfügung hast.

Viel einfacher und sauberer als das wird es nicht.

Dass die Mutex Locks dabei blockierend sind sollte egal sein, da die Locks immer nur für einen sehr kurzen Zeitraum gehalten werden. Das .NET Framework macht im Hintergrund auch nix anderes.

Da Mutexes also weniger schlimm sind als ich bisher immer dachte (ich dachte, dass sie viel länger blockieren), bin ich mit einer solchen Lösung voll zufrieden: http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html (siehe unten bei "The Final Code").

Das einzige Problem an dieser Implementierung ist die Benutzung von Boost. Ich möchte diese Library nicht verwenden, auch wenn sie oft als "well-known" und als quasi-standard betrachtet wird.

Gibt es vergleichbare Implementation dazu, ohne Boost? boost::mutex & boost::mutex::scoped_lock sind ja relativ einfach zu ersetzen. Nur wie man boost::condition_variable umsetzt, erschließt sich mir nicht...

Gibt es vergleichbare Implementation dazu, ohne Boost?

Ja, klar.
Dazu müsste man aber erstmal wissen was für eine Threading-API du verwendest.

grundsätzlich bleibe ich erst einmal auf Windows, und möchte das später auch auf Linux machen (erst einmal zweitrangig). Also für mich wäre eine systemnahe Implementation am interessantesten, um zu lernen, wie ich damit umzugehen habe...

Gruß

grundsätzlich bleibe ich erst einmal auf Windows

Dann schau dir die Doku zu
CreateMutex
WaitForSingleObject
ReleaseMutex
an.

Ich würde dennoch mit boost threads arbeiten. Spart ne Menge Arbeit und gibt dir genug verstädnis für die Materie. IMHO ist boost thread sogar besser, weil du nicht durch Implementierungsdetails abgelenkt bist. Ein boost mutex ist zB viel schöner und klarer als ein Win32 mutex

zu spät - ich habe den Sinn von Condition Variables und Mutexes (bzw. den Vorteil von Critical Sections unter Windows) nun verstanden und konnte daher eigene Wrapper implementieren.

Wenn ich nachher die Möglichkeit habe, das Ganze hochzuladen, werde ich das tun, falls Interesse besteht (und damit eventuell mal einer kurz rüberschauen kann).

Danke an alle

Ich finde es übrigens lustig, dass so etwas Essentielles erst ab Windows Vista verfügbar ist (also nativ implementiert)

Ich finde es übrigens lustig, dass so etwas Essentielles erst ab Windows Vista verfügbar ist (also nativ implementiert)

Was meinst du?

Windows Server 2003 and Windows XP: Condition variables are not supported.

ich habe den Sinn von Condition Variables und Mutexes (bzw. den Vorteil von Critical Sections unter Windows)

Nur ein Hinweis: Critical Sections unter Windows *sind* Mutexen. Bloss ein anderer Name, und man kann sie halt nicht prozessübergreifend verwenden.
Das was Windows "Mutex" nennt ist ein Kernel-Objekt, und als solches ziemlich langsam.

Wenn ich nachher die Möglichkeit habe, das Ganze hochzuladen, werde ich das tun, falls Interesse besteht (und damit eventuell mal einer kurz rüberschauen kann).

Tu das, drüberschauen kann ich auf jeden Fall mal.

Ich finde es übrigens lustig, dass so etwas Essentielles erst ab Windows Vista verfügbar ist (also nativ implementiert)

Naja, Windows hat statt Condition-Variablen sog. "Events" angeboten. Mit denen kann man auch ganz gut arbeiten, allerdings nicht ganz so unkompliziert und problemlos wie mit Condition-Variablen.

Weil auf quasi allen nicht-Windows Systemen aber Condition-Variablen "Standard" sind, und es auch nicht ganz trivial ist Condition-Variablen mit Windows Boardmnitteln (also Critical-Sections, Events etc.) performant und korrekt nachzubilden, hat MS mit Windows Vista endlich "native" Condition-Variablen nachgereicht. Damit Windows auch endlich Condition-Variablen hat, und die Protierung von Projekten auf Windows einfacher wird.

Wenn Support für XP/2003 für dich nicht wichtig ist dann nimm einfach die native Windows Condition-Variablen. Wenn Support für XP/2003 doch wichtig ist, dann würde ich auch zu Boost.Thread, Qt oder einer anderen Library raten, die Condition-Variablen unter Windows XP/2003/... anbietet.
Weil es wie gesagt nicht ganz trivial ist das selbst zu stricken, und eine Queue aus der mehrere Threads lesen ist mit Events auch nicht ganz einfach.

theliquidwave schrieb:

grundsätzlich bleibe ich erst einmal auf Windows

Dann schau dir die Doku zu
CreateMutex
WaitForSingleObject
ReleaseMutex

Verlinkst du absichtlich die Windows XxxMutex Funktionen? Weil die ausser langsam nur langsam sind? Damit du nachher sagen kannst "nimm Boost, dann wird das alles auch viel schneller"? Oder ...?

Oder ist dir nur einfach nicht klar dass es unter Windows Critical-Sections gibt, und dass Critical-Sections Mutexen *sind*, nur eben ... besser als die Kernel-Mutexen?

Verlinkst du absichtlich die Windows XxxMutex Funktionen?

Es sind Stichworte mit denen man den Rest easy finden kann. Ich haette mir auch raussuchen koennen wie die Critical Sections heissen, war aber dazu zu faul.

Mit der MFC gehts ueber ein CSingleLock aber wie das mit der WinAPI geht, keine Ahnung.

hustbaer schrieb:

Verlinkst du absichtlich die Windows XxxMutex Funktionen?

Es sind Stichworte mit denen man den Rest easy finden kann. Ich haette mir auch raussuchen koennen wie die Critical Sections heissen, war aber dazu zu faul.

Und weil du zu faul warst EnterCriticalSection() und LeaveCriticalSection() zu ergoogeln hast du lieber Critical-Section gleich gar nicht erwähnt?
Wie macht das denn Sinn?

Wenn du denkst, dass die Information zu Critical Sections wichtig ist, dann schreib sie einfach hin, no biggy

Nur ein Hinweis: Critical Sections unter Windows *sind* Mutexen. Bloss ein anderer Name, und man kann sie halt nicht prozessübergreifend verwenden.
Das was Windows "Mutex" nennt ist ein Kernel-Objekt, und als solches ziemlich langsam.

Ich weiß, deshalb habe ich ja auch geschrieben:

theliquidwave schrieb:

(bzw. den Vorteil von Critical Sections unter Windows)

Trotzdem danke für den Hinweis

hustbaer schrieb:

Tu das, drüberschauen kann ich auf jeden Fall mal.

Danke, mache ich morgen...

hustbaer schrieb:

Naja, Windows hat statt Condition-Variablen sog. "Events" angeboten. Mit denen kann man auch ganz gut arbeiten, allerdings nicht ganz so unkompliziert und problemlos wie mit Condition-Variablen.

Okay.

hustbaer schrieb:

Weil die ausser langsam nur langsam sind?

In der MSDN steht nur, dass Critical Sections "sligthy faster" sind als Mutexes...

hustbaer schrieb:

Weil die ausser langsam nur langsam sind?

In der MSDN steht nur, dass Critical Sections "sligthy faster" sind als Mutexes...

Uff. Ich müsste den Unterschied mal ausmessen. Würde mich aber wundern wenn es nur "sligthy" wäre.

Critical-Sections sind Usermode spin-sleep Locks, also das schnellste was man so an nicht spezialisierten Mutexen bauen kann.

Ne Win32 Mutex ist dagegen wie gesagt ein Kernel-Objekt. D.h. es müssen mehrere Dinge passieren wenn man damit was machen will

1. Kernelmode-Transition
2. Handle-Lookup & Ermittlung des Handle-Typs
3. Security-Check, inklusive Check ob der aufrufende Prozess überhaupt berechtigt ist mit dem übergebenen HANDLE zu arbeiten
4. Die eigentliche Aktion
5. Transition zurück in den Usermode

Mit MSVC 2012 std::chrono::high_resolution_clock (aka. GetSystemTimeAsFileTime()):

class CriticalSectionNoDebugInfo create/destroy = 2929 us (base)
class CriticalSectionNoDebugInfo create/lock/unlock/destroy = 8789 us (base)
class CriticalSectionNoDebugInfo lock/unlock = 47851 us (base)

class CriticalSection create/destroy = 31250 us = 10.6666 * base
class CriticalSection create/lock/unlock/destroy = 35156 us = 3.99998 * base
class CriticalSection lock/unlock = 46875 us = 0.979593 * base

class Win32Mutex create/destroy = 193359 us = 65.9997 * base
class Win32Mutex create/lock/unlock/destroy = 308593 us = 35.111 * base
class Win32Mutex lock/unlock = 1149414 us = 24.0204 * base

Mit my_highres_clock aka. QueryPerformanceCounter():

class CriticalSectionNoDebugInfo create/destroy = 3691 us (base)
class CriticalSectionNoDebugInfo create/lock/unlock/destroy = 8498 us (base)
class CriticalSectionNoDebugInfo lock/unlock = 46898 us (base)

class CriticalSection create/destroy = 30244 us = 8.19254 * base
class CriticalSection create/lock/unlock/destroy = 34650 us = 4.07736 * base
class CriticalSection lock/unlock = 46955 us = 1.00123 * base

class Win32Mutex create/destroy = 192070 us = 52.0267 * base
class Win32Mutex create/lock/unlock/destroy = 307289 us = 36.1587 * base
class Win32Mutex lock/unlock = 1144865 us = 24.4117 * base

"sligthy faster" kommt also nicht so ganz hin. > Faktor 20 ist bei mir nicht mehr "sligthy"

3. Security-Check, inklusive Check ob der aufrufende Prozess überhaupt berechtigt ist mit dem übergebenen HANDLE zu arbeiten

OK, "Security-Check" ist Quatsch, der ist nur nötig wenn man versucht ein neues HANDLE zu bekommen, und das tut man bei WaitForSingleObject/ReleaseMutex ja nicht.
Der Check ob der aktuelle Prozess mit diesem HANDLE arbeiten darf ist hier denke ich schon nötig. HANDLE-Werte sind IIRC ja prozessübergreifend, aber nicht jeder Prozess darf mit jedem HANDLE arbeiten.