die threads sind im testprogramm per winapi implementiert und die cpu-auslastung bei meinen dualcore (e6600) steigt nur auf 70%

wenn ich die threads per SDL-bibliothek implementiere läuft das programm schneller und die cpu-auslastung ist auf 100%

gibt es einen weg die auslastung auch per winapi auf 100% zu bringen ?

danke schonmal

#include <stdio.h>
#include <windows.h>

DWORD WINAPI ThreadFunktion0(LPVOID param)
{
	for(int a=0; a<=100000 ;a++){
	printf("thread1\n");
	}
	return 0;
}

DWORD WINAPI ThreadFunktion1(LPVOID param)
{
	for(int b=0; b<=100000; b++){ 
	printf("thread2\n");
	}
	return 0;
}

DWORD WINAPI ThreadFunktion2(LPVOID param)
{
	for(int c=0; c<=100000; c++){ 
	printf("thread3\n");
	}
	return 0;
}

DWORD WINAPI ThreadFunktion3(LPVOID param)
{
	for(int d=0; d<=100000; d++){ 
	printf("thread4\n");
	}
	return 0;
}

int main()
{
	DWORD threadId = 0;
	HANDLE threadHandle0 = CreateThread(
		0, // keine Security
		0, // default-Stack
		ThreadFunktion0,
		0, // kein Parameter
		0, // normal erzeugen
		&threadId // threadId
		);

	HANDLE threadHandle1 = CreateThread(
		0, // keine Security
		0, // default-Stack
		ThreadFunktion1,
		0, // kein Parameter
		0, // normal erzeugen
		&threadId + 1 // threadId
		);

	HANDLE threadHandle2 = CreateThread(
		0, // keine Security
		0, // default-Stack
		ThreadFunktion2,
		0, // kein Parameter
		0, // normal erzeugen
		&threadId + 2 // threadId
		);

	HANDLE threadHandle3 = CreateThread(
		0, // keine Security
		0, // default-Stack
		ThreadFunktion3,
		0, // kein Parameter
		0, // normal erzeugen
		&threadId + 3 // threadId
		);

	WaitForSingleObject(threadHandle0, INFINITE);
	WaitForSingleObject(threadHandle1, INFINITE);
	WaitForSingleObject(threadHandle2, INFINITE);
	WaitForSingleObject(threadHandle3, INFINITE);
	printf("\nEnd\n");
	getchar();

return 0;
}

Liegts vieleicht an der Priorität der Threads? Setz mal alle auf Realtime.

Solange CPU-Power frei ist, müsste sie eigentlich genutzt werden.
Ich tippe einfach mal, dass die Konsole irgendwie blockiert oder irgendwo mit auf-irgendwas-warten Zeit verbraucht wird (dann eben nicht CPU-Zeit). Denn wenn du nur Berechnungen durchführen lässt (ohne Ausgabe), sitzt sie Auslastung exakt auf 100%.

Btw ist das hier &threadId + 1 so ziemlich gar nicht gut! Du willst/sollst ja einen Zeiger auf eine Variable übergeben, die die Thread-ID empfängt. Mit dem "+1" übergibst du eine Speicherstelle, die nicht mehr mit der Variable "threadId" übereinstimmt, sondern darüber hinaus schreibt.

Und, abgesehen davon, kannst du auch mehrere Threads mit der selben Threadfunktion gleichzeitig starten, es sollten darin nur keine statischen Variablen verwendet werden. Die lokalen Variablen der Threadfunktion landen ja bei mehreren parallelen Threads alle auf einem anderen Stack-Bereich.

=>

#include <stdio.h>
#include <windows.h>

DWORD WINAPI ThreadFunktion(LPVOID param)
{
	// Irgendeine sinnlose Berechnung:
	int x = 0;
	for(int b=0; b<=1000000 ;b++)
		for(int a=0; a<=1000000 ;a++){
			x *= a;
	    }
    return 0;
}

int main()
{
	static const int THREAD_COUNT = 4;
    DWORD threadIds[THREAD_COUNT];
	HANDLE threadHandles[THREAD_COUNT];

	for ( int i=0; i<THREAD_COUNT; i++ )
		threadHandles[i] = CreateThread( 0, 0, ThreadFunktion, 0, 0, &threadIds[THREAD_COUNT] );

	for ( int i=0; i<THREAD_COUNT; i++ )
        WaitForSingleObject( threadHandles[i], INFINITE);

	printf("\nEnd\n");
    getchar();

	return 0;
}

Für C-Code eben die Konstante "THREAD_COUNT" mit #define deklarieren oder als enum-Wert benutzen; "int i" auch vor der Schleife deklarieren.

aber ich glaube nicht das es an printf liegt, da dass in meinem anderen programm auch verwendet wird

und in dem oben genannten beispiel machen alle threads die gleiche berechnung -> sie sollen aber verschiedene machen (arbeitsteilung)

Warum willst Du denn unbedingt so viel CPU-Kapzität verbraten. Schließlich braucht das Betriebssystem auch noch einige Reserven, um seine Aufgaben zu erledigen.

So lange die Threads / der Prozess Rechenzeit abgibt, wenn andere Prozesse sie brauchen, ist das kein Problem. Ich meine du schleichst ja auch nicht mit deinem Auto mit 30 über die Autobahn, obwohl es 140 schafft. Also ich habe meine CPU zum Rechnen gekauft und nicht zum Schlafen.

aber ich glaube nicht das es an printf liegt, da dass in meinem anderen programm auch verwendet wird

Na und! Was hat die Aussage, dass Du es woanders verwendest mit dem Problem hier zu tun.

Jochen hat recht.
Es gibt in der CRT speziell eben auch bei der Ausgabe auf stdout eine Synchronisation, wenn Du das so machst. Dadurch warten mehr oder weniger eben ein Thread auf den anderen, weil eben nur ein Thread jeweils zu einer Zeit auf stdout schreiben kann.

Nimm mal die printf's raus und ersetze sie durch eine log oder sonst was rechenintensives und Du wirst Deine 100% Last bekommen...

Nimm mal die printf's raus und ersetze sie durch eine log oder sonst was rechenintensives und Du wirst Deine 100% Last bekommen...

Nicht wenn das "log" über printf implementiert ist

p.S.: Ich weiss seit heute z.B. auch dass ein ::CreateDirectory() in einer Endlosschleife auf einem Dual Core bloss einen Core voll auslastet. Hihi. Nicht dass ich es ausprobieren wollte...
(Zumindest unter Win2003 auf nem VMware ESX Server)

p.S.: Ich weiss seit heute z.B. auch dass ein ::CreateDirectory() in einer Endlosschleife auf einem Dual Core bloss einen Core voll auslastet. Hihi. Nicht dass ich es ausprobieren wollte...

Eigentlich blöd, einer könnte ja schonmal mit Create anfangen, während der andere noch das Directory sucht

Eine Single-Core Maschine ist auf jeden Fall komplett "dicht" sobald da bloss ein solcher Thread läuft, da braucht es schonmal ein paar Minuten bis man bloss den Task-Manager offen hat.
Auf einer Dual Core Maschine geht die CPU Last nicht höher als 50%, und man kann normal weiter arbeiten als ob garnix wäre.

Der Zugriff wird wahrscheinlich exklusiv durchgeführt (über CS/Mutex) gelockt, so daß sich sowieso immer nur ein thread damit beschäftigen darf.

Weiterhin sind die notwendigen Plattenzugriffe evtl. asynchron und erzeugen keine CPU - Last - nach ein paar iterationen solltest das aber alles in Cache liegen.

Das kann sich aber auch je nach Hardware und OS unterscheiden.

hat nur irgendwie zum Thema gepasst, und da ich das kürzlich erst beobachten konnte

Recht so! Hab' schön geschmunzelt