ZFX + Developia

Yield-Schleifen sind übel für das Betriebssystem. Wenn grad nix zu tun ist, kriegt der Nutzer damit ein ganzes Bündel hässlicher Effekte, schlimmstenfalls die Rückkehr der guten alten sprunghaften Maus.

Ich werde meine Zeit nicht für noch eine Diskussion dieser Art verschwenden.

Ich erinnere mich, dass x86 einen speziellen Spinlock-Befehl hat, den die CPU auch als „warte und schieb andere Hyperthreads dazwischen;

Ansonsten habe ich mir den Quelltext nicht weiter angeschaut weil ich nicht wirklich begriffen habe, was er tun soll.

void yield();
Provides a hint to the implementation to reschedule the execution of threads

"Pause" macht etwas völlig anderes.
Pause ist Teil von SSE2 und bremst den Prozessor für Busy Waits(Spinloops) etwas, ohne mehr Rechenkapazität und Strom zu verschwenden als nötig ist und sollte dafür eine leicht schonendere Umsetzung erlauben.

Am Wichtigsten ist es lange von kurzen Pausen zu unterscheiden

andere Ansätze anschauen wie das Suspend/Resume, Condition Variablen etc.

Das sieht aus als ob du zu viele Threads für deinen Zweikerner erzeugst.

ResumeThread() und SuspendThread() sind nicht zur Synchronisierung gedacht und sollten auch nicht dafür verwendet werden.

Auch verstehe ich wie Schrompf deinen Code nicht. Nirgendswo wird irgendeine Arbeit gemacht.

Er meint mit Synchronisierung wohl mehr sowas wie WaitForMultipleObjects(ALL), glaube ich … jedenfalls arbeitet das Konzept im Augenblick so.

Horus hat geschrieben:

andere Ansätze anschauen wie das Suspend/Resume, Condition Variablen etc.

ResumeThread() und SuspendThread() scheinen prinzipiell gut geeignet. Leider ist es mit damit noch nicht gelungen.

MSDN hat geschrieben:This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. [...]

Horus hat geschrieben:

ResumeThread() und SuspendThread() sind nicht zur Synchronisierung gedacht und sollten auch nicht dafür verwendet werden.

Das ist mir bekannt, jedoch erscheint das Konzept sinnvoll, um mehrere Threads die warten müssen aus dem "busy wait" zu bekommen.
Ich glaube "CriticalSections" helfen mir nicht bei "warten lassen" von Threads auf einander.

Nein, die sind überhaupt nicht für sowas geeignet, steht sogar extra der Hinweis in der MSDN

Schau dir mal Condition Variablen, Events, I/O Completion Ports etc. an.

Versteh ich das richtig, dass alle Workerthreads gleichzeitig anfangen zu arbeiten und der Mainthread darauf wartet dass alle fertig werden und dann wieder alle Workerthreads mit was neuem anfangen?

Die einfachste Lösung wäre dann tatsächlich WaitForMultipleObjects. Dann musst du die Threads aber für jede Aufgabe neu erstellen.

Der Mainthread kann dann über ein zweites Event wieder alle Threads aufwecken.

Horus hat geschrieben:

Der Mainthread kann dann über ein zweites Event wieder alle Threads aufwecken.

Wenn ich es so mache, wie schlafen sie?

Dass ist nett, dass du ein minimales Beispiel gemacht hast.

Du brauchst allerdings mindestens zwei Events. Die Racecondition hast du ja schon selber erkannt. Ohne Mainthread ist das etwas tricky, aber es geht so:

Performanter kann man so ein Problem nicht lösen.

Du musst auch bedenken, dass sobald ein Thread länger braucht als die anderen er alle blockieren wird

Das Problem ist aber sehr komisch und mich würde interessieren, wozu du sowas brauchst.

#include <windows.h>
#include <thread>
#include <atomic>

#define THREADCOUNT 4

std::thread Threads[THREADCOUNT];
HANDLE TestEvent1, TestEvent2;

std::atomic<size_t> ThreadCounter = 0;

bool TestRunning1 = true;

size_t WaitForAllThreads()
{
	const size_t Count = ThreadCounter.fetch_add(1);
	HANDLE NextEvent = TestRunning1 ? TestEvent2 : TestEvent1;
	if (Count == THREADCOUNT - 1)
	{
		ThreadCounter = 0;
		ResetEvent(TestRunning1 ? TestEvent1 : TestEvent2);
		TestRunning1 = !TestRunning1;
		SetEvent(TestRunning1 ? TestEvent1 : TestEvent2);
	}
	else
		WaitForSingleObject(NextEvent, INFINITE);
	return Count;
}
bool Run = true;

void ThreadFunction(const size_t Id)
{
	while (Run)
	{
		printf("step 0\n");
		WaitForAllThreads();
		printf("step 1\n");
		if (WaitForAllThreads() == 0) // pick only one thread
			printf("sort \n");
		WaitForAllThreads();
	}
}

int main()
{
	TestEvent1 = CreateEvent(
		NULL,               // default security attributes
		TRUE,               // manual-reset event
		FALSE,              // initial state is nonsignaled
		NULL                // object name
		);
	TestEvent2 = CreateEvent(
		NULL,               // default security attributes
		TRUE,               // manual-reset event
		FALSE,              // initial state is nonsignaled
		NULL                // object name
		);

	for (size_t i = 0; i < THREADCOUNT; ++i)
		Threads[i] = std::thread(&ThreadFunction, i);

	getchar();
	bool Run = false;

	for (size_t i = 0; i < THREADCOUNT; ++i)
		Threads[i].join();

	getchar();
}

Du solltest vielleicht auch noch TestRunning1 volatile markieren [...]

Ja, man sollte wohl wirklich aus dem bool ein std::atomic<bool> machen.

Gibt's zu Win32 Events eigentlich auch ein Pendant in der Standard Bibliothek?

Horus hat geschrieben:Ich arbeite seit längerem an einem "seltsamen" Computerspiel.
https://www.youtube.com/watch?v=zS95WIw ... d6RXN5IteB
Die Engine ist mittlerweile ein echtes Kraftpaket.
Ich habe viel Zeit in Optimierung, SIMD, Datenorientierung usw. gesteckt. Tatsächlich kann man sagen für dieses Projekt habe ich C++ gelernt.
Um alle richtig flüssig zu simulieren sind Updatefrequenzen um die 1000Hz in der Engine nötig.
50.000 und komplexen Partikeln und mehr, bei Modernen CPUs, trotz der hohen Frequenz kein Problem.

Ja, man sollte wohl wirklich aus dem bool ein std::atomic<bool> machen. Aber solange man Visual Studio verwendet reicht auch volatile.

Ich hatte vergessen zu sagen, dass das fantastisch aussieht :-)

Aramis hat geschrieben:Es ist weniger Visual Studio als der Umstand, das die x86 und die AMD64-Architektur kein relevantes Memory-Reordering durchfuehren und volatile somit ausreichend ist, da es immerhin alle compiler-generierten Umordnungen verhindert.