C++11 Concurrecny und CLI

Hallo zusammen,

ich entwickel momentan eine Bibliothek für Multithreading (soll auch in .NET laufen). Jetzt besitzen meine Schnittstellen aber eine Komponenten wie z.B. std::promise.

Beim Compilieren der Anwendung / Komponente mit CLI, erhalte ich die Meldung

<mutex> is not supported when compiling with /clr or /clr:pure.
usw.

Jetzt verwende ich wo möglich das PIMPL Idiom.

Meine Frage:
Muss die Header welche z.B. die besagten Nebenläufigen Komponenten einsetzt (promise), diese bereits inkludieren, oder kann ich diese in die Implementierungs-Datei erst inkludieren?!

Marc-O

Hallo

Kommt drauf an ob promise als Parametertyp, Rückgabetyp oder Membertyp verwendet wird. Wenn ja dann brauchst du den include, sonst nicht.

Gruß Marco

Techel

Wenn man die Klasse instanzieren möchte musst du <mutex> natürlich instanzieren.

Marc-O schrieb:

Hallo

Kommt drauf an ob promise als Parametertyp, Rückgabetyp oder Membertyp verwendet wird. Wenn ja dann brauchst du den include, sonst nicht.

Gruß Marco

Ja wird als Parameter an die Schnittstelle übergeben.

Alternative ist dann wohl eine Eigen Implementierung von future / promise, oder?

dot

Nur mal rein prinzipiell: Was genau soll diese "Bibliothek für Multithreading" eigentlich abdecken und wieso muss sie sowohl mit native als auch mit CLI funktionieren?

Techel

Dann übergeb es per const-referenz, so braucht es nur eine Forwärtsdeklaration. Einen Mutex per value übergeben ist eh nicht sinnvoll (überhaupt ist es nicht sinnvoll einen Mutex irgendwohin zu übergeben, oder?)

roflo schrieb:

Dann übergeb es per const-referenz, so braucht es nur eine Forwärtsdeklaration. Einen Mutex per value übergeben ist eh nicht sinnvoll (überhaupt ist es nicht sinnvoll einen Mutex irgendwohin zu übergeben, oder?)

Die Mutex Zitat war nur ein Beispiel und Auszug aus der <mutex> Header Datei.

Gemeint war std::promise.

Zum Vorschlag: Ich übergebe die promise Instanz als R-Value, da Promise nicht kopierbar ist.

Techel

Oder als const-referenz.

roflo schrieb:

Oder als const-referenz.

Das wird doch nicht funktionieren. Ich übergebe die promise objekte in einer Funktion / Methode. Verlasse ich diese wird die Ressource (promise) freigegeben und ich habe dann eine ungültige Referenz auf das Objekt.

Techel

Warum sollte die bitte freigegeben werden?

roflo schrieb:

Warum sollte die bitte freigegeben werden?

Future<int> a_future;
void SomeFunction()
{
	TaskManager& pool = TaskManager::Instance();

	Promise<int> a_promise; // <<--- a_promise ist nicht mehr im stack nach verlassen der funtion...
	a_future = a_promise.GetFuture();

	auto status = pool.Submit( 
              Task( FunctionHolder( std::bind(complex_callculation), a_promise)) // a_promise als referenz übergeben
        ); 
}

Techel

Dann musst du schon etwas genauer beschreiben, was du erreichen möchtest
Das Promise-Objekt muss bei deinem Beispiel mindestens so lange leben wie der Task ausgeführt wird.

roflo schrieb:

Dann musst du schon etwas genauer beschreiben, was du erreichen möchtest
Das Promise-Objekt muss bei deinem Beispiel mindestens so lange leben wie der Task ausgeführt wird.

Genau und deshalb habe ich bisher das Promise Objekt per Move verschoben an den functionholder. Die Möglichkeit per const Referenz ist damit nicht möglich.

Kennt ihr den Grund wieso das explizit verboten wird zu kompilieren?