Gut, nun zum eigentlichen...
Ich möchte eine Klasse aufbauen die Daten (Variablen types) thread sicher verwaltet und gleichzeitig maximale Geschwindigkeit hat.

Mein jetziger Ansatz war über Mutex und sieht wie folgt aus:

template<class T>
class ThreadSaveData
{
private:
    T* m_data;
    HANDLE m_mutex;

public:

    ThreadSaveData<T>(T p_data);
    ~ThreadSaveData<T>(void);

    void setData(T p_data, unsigned int p_timeout = 5000);    
    T getData(unsigned int p_timeout = 5000);
};

template <class T>
ThreadSaveData<T>::ThreadSaveData(T p_data)
{
	m_data = new T;
	m_mutex = CreateMutex(NULL,true,this);

	if(!m_mutex)
	{
		throw(0);
	}
	else
	{
		ReleaseMutex(m_mutex);
	}
}

template <class T>
ThreadSaveData<T>::~ThreadSaveData(void)
{
	if(WaitForSingleObject(m_mutex, INFINITE)==WAIT_TIMEOUT) 
	{
		std::cout<<"Mutex kann nicht freigegeben werden"<<std::endl;
		Sleep(2000);
		throw(0);//exit(1);
	}
	else
	{
		delete m_data;
		CloseHandle(m_mutex);
	}
}

template <class T>
void ThreadSaveData<T>::setData(T p_data, unsigned int p_timeout)
{
	if(WaitForSingleObject(m_mutex, p_timeout)==WAIT_TIMEOUT) 
	{
		std::cout<<"Mutex kann nicht freigegeben werden"<<std::endl;
		Sleep(2000);
		throw(0);//exit(1);
	}
	else
	{
		*m_data = p_data;
		ReleaseMutex(m_mutex);
	}
}

template <class T>
T ThreadSaveData<T>::getData(unsigned int p_timeout)
{
	if(WaitForSingleObject(m_mutex, p_timeout)==WAIT_TIMEOUT) 
	{
		std::cout<<"Mutex kann nicht freigegeben werden"<<std::endl;
		Sleep(2000);
		throw(0);//exit(1);
	}
	else
	{
		T p_data = *m_data;
		ReleaseMutex(m_mutex);
		return p_data;
	}
}

Soweit so gut, mir wurde aber jetzt gesagt das diese Möglichkeit alles andere als schnell sein soll.
Stattdessen wurde mir zu einer Kombination aus einem im Hintergrund laufenden Verwaltungsthread und Events geraten, dies soll mehrkern optimierter sein.

Könnt ihr dazu was sagen? Ich habe keine Ahnung wie ich die Daten aus einem Verwaltungsthread zum aufrufenden Thread bekommen soll...

Mfg. Matyr

Edit: angemerkte Fehler wurden geändert bzw. markiert

http://www.relisoft.com/win32/active.html / http://msdn.microsoft.com/en-us/library/ms686927(v=VS.85).aspx

Prinzipiell spricht aber erstmal nichts dagegen hier einen Mutex zu verwenden. Erstmal richtig machen, und dann schnell.

Aber wenn es eh eine effektivere Möglichkeit für die ganze Verwaltung gibt verschindet das Problem ja eh.

exit(..) in C++ ist typischerweise keine gute Idee. Es werden keine Destruktoren aufgerufen.

Quelle bitte

The function exit()has additional behavior in this International Standard:
— First, objects with static storage duration are destroyed and functions registered by calling atexit are called. Non-local objects with static storage duration are destroyed in the reverse order of the completion of their constructor. (Automatic objects are not destroyed as a result of calling exit().)²⁰⁷⁾ Functions registered with atexit are called in the reverse order of their registration, except that a function is called after any previously registered functions that had already been called at the time it was registered.²⁰⁸⁾ A function registered with atexit before a non-local object obj1 of static storage duration is initialized will not be called until obj1’s destruction has completed. A function registered with atexit after a non-local object obj2 of static storage duration is initialized will be called before obj2’s destruction starts. A local static object obj3 is destroyed at the same time it would be if a function calling the obj3 destructor were registered with atexit at the completion of the obj3 constructor.
— Next, all open C streams (as mediated by the function signatures declared in <cstdio>) with unwritten buffered data are flushed, all open C streams are closed, and all files created by calling tmpfile() are removed.²⁰⁹⁾
— Finally, control is returned to the host environment. If status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.²¹⁰⁾

²⁰⁷⁾ Objects with automatic storage duration are all destroyed in a program whose function main() contains no automatic objects
and executes the call to exit(). Control can be transferred directly to such a main() by throwing an exception that is caught in
main().
²⁰⁸⁾ A function is called for every time it is registered.
²⁰⁹⁾ Any C streams associated with cin, cout, etc (27.3) are flushed and closed when static objects are destroyed in the previous
phase. The function tmpfile()is declared in <cstdio>.
²¹⁰⁾ The macros EXIT_FAILUREand EXIT_SUCCESSare defined in <cstdlib>.

Reicht dies als Quelle?

Grüssli

Da wird ja relativ genau auf CS und Interlock (was immer das auch ist) eingegangen.

Die Frage bleibt, ist es effektiver das ganze irgendwie über Events und einem Daten-Verwaltungs-Thread zu machen oder so wie es jetzt ist.

Die Frage bleibt, ist es effektiver das ganze irgendwie über Events und einem Daten-Verwaltungs-Thread zu machen oder so wie es jetzt ist.

Unterschiedliche Anforderungen bringen unterschiedliche Ergebnisse.

Prinzipiell ist dein Ansatz passend.

Wenn du zB in ThreadSaveData nur primitive Typen hältst ist ein InterlockedExchange() wahrscheinlich das schnellste. Das Stichwort hier wäre CAS (compare and set/swap).

Crtitcal Sections sind nicht über mehrere Prozesse Hinweg benutzbar dafür idR einen Tick schneller als Mutexes.

Die Performance spielt aber nur dann eine Rolle wenn du oft für kurze Zeit lockst. Wenn du selten für lange Zeit lockst ist es komplett egal.

Das mit den Events und Verwaltungsthread verstehe ich nicht. Kannst du erklären was da gemeint ist?

Und: Was ist das Anforderungsprofil?

Das was ich mit Verwaltungsthread meine ist ein SON (service orientatet network oder so) system.

Daher ein Thread auf den man mit events zugreift und der den anderen Threads bescheid gibt das Daten belegt werden. (Wenn ich das richtig verstanden habe)
Dadurch soll eine höhere Geschwindigkeit gewährleistet sein und vor allem viel Dynamischer.

Problem ist vielleicht nur das wenn das lesen länger als ein Takt dauert und dann etwas Anfängt zu schreiben...

Deswegen wird beim Schreiben der Mutex gesetzt, in der lese Funktion wird einfach nur geprüft ob er gesetzt wurde, wenn ja wartet er, wenn nicht wird einfach gelesen.

Problem ist vielleicht nur das wenn das lesen länger als ein Takt dauert und dann etwas Anfängt zu schreiben...

richtig - deshalb schrieb ich ja, dass es schief geht, wenn ein thread gerade schreibt und der andere liest... (bzw schief gehen kann - nicht muss)

Nun ist die Frage wie ich die Geschwindigkeiten der beiden mal messen bzw. vergleichen kann. Die Zeit zu messen wird denke ich zu ungenau. Effektiv ist wahrscheinlich ein vergleich der Rechenschritte,
nur weiß ich leider nicht wie das effektiv geht.

Ist clock(); ein vernünftiger Ansatz?

Ist clock(); ein vernünftiger Ansatz?

Nö, dafür eignet sich eher QueryPerformanceCounter() (siehe MSDN).

Zeit normalle CS: 3400
Zeit meine CS: 2000

Kann aber wegen Optimierung des Compilers vielleicht falsch sein.
Initialisieren ist etwas langsamer, schätzungweise 5-10% was aber anhand der anderen Ergebnisse verkraftbar ist.

Mfg. Matyr

Folgendes Messverfahren:

QueryPerformanceCounter((LARGE_INTEGER*)&count1);
    for(int i=0;i<30000;i++)
    {
        EnterCriticalSection(&cs);    
        LeaveCriticalSection(&cs);    
    }
    QueryPerformanceCounter((LARGE_INTEGER*)&count2);
    cout<<"Enter/Leave CS: "<<(count2-count1)<<endl;

    Sleep(50);

    QueryPerformanceCounter((LARGE_INTEGER*)&count1);
    for(int i=0;i<30000;i++)
    {
        myCs.Lock();    
        myCs.Unlock();
    }
    QueryPerformanceCounter((LARGE_INTEGER*)&count2);
    cout<<"Enter/Leave MyCS: "<<(count2-count1)<<endl;