ich starte meinen thread über den (zum teil geposteten) Konstruktor und will, dass er läuft - so lange, bis ich meinen Destruktor aufrufe, da der Thread genau wie ne normale Klasse arbeiten soll - also immer laufen soll, nur eben nicht im "main"-thread...
Geht das, oder ist das mit nem Thread prinzipiell unmöglich? Wenn es geht (was ich mal ganz stark vermuten würde ^^), wie?

Danke schon mal

Grüße Joe_M.

Danke...

Bezüglich Events:
CreateEvent
SetEvent
KillEvent

Der Unterschied zwischen Events/Semaphores ist, das mit Botschaften ein spezifischer Thread angesprochen wird, aber bei Events/Semaphores alle Threads angesprochen werden (können) und ein beliebiger die Arbeit ausführt. Man kann also nicht festlegen, welcher der Threads die Arbeit übernimmt. Beide Vorgehensweisen haben ihre Vorteile. Welche man einsetzt wird normalerweise vom Anwendungskonzept bestimmt. Da Du anscheinend bestimmte Aufgaben an bestimmten Objekten durchführen willst, sind vermutlich Botschaften die bessere Wahl.

Bedenke bitte auch, dass Du den Zugriff auf Objekte, die sowohl im Thread, als auch im Application-Thread verwendet werden, z.B. über eine CriticalSection gegen gleichzeitigen Zugriff abgesichert werden müssen.

class a : private TThread
{
class b : private TThread
{
TServerSocket *x;
//usw...
};
DynamicArray <b*> B;
};

je nach dem, wie viele clients zu meinem Server verbunden sind und je nach dem, wie viele das in den letzten paar sekunden zu dem sockel xyz getan haben, startet der thread a beliebig viele sockets (und die zugehörigen arrays von userdaten) b...
events weiß ich, wie die funktionieren - hab ich auch zur genüge drin, weil mysql und so ja auch was zu tun haben will ^^
aber ich bräuchte halt trotzdem noch nen thread, weil sonst ist es auch sinnlos, mehrere sockets zu starten... ohne das hab ich aber nen extrem großes problem, wenn zum bsp. 50 clients zeitgleich connecten, dann is der server hoffnungslos überlastet und lässt einfach alles sein ^^
kann jmd von euch vll mal die schleife im execute schreiben, wie ihr das meint? (man hört sich das noobig an... xD)
warum ich mich wunder:
wenn ich im execute nichts mach, muss ich den thread pausieren lassen, sonst terminated er sich... wenn ich aber was mach, wird der thread kaum nebenbei noch das event oder die fkt. behandeln, weil er ja im execute was macht... oder seh ich das falsch?

void __fastcall TTestThread::Execute()
{
	try
	{
		ReturnValue = 0;
		MAX_HANDLES = 3;
		try
		{
			HANDLEARRAY = NULL;
			HANDLEARRAY = new HANDLE[MAX_HANDLES];

			HANDLEARRAY[0] = hEventGlobalTerminationRequest;	// für Einleitung Programmende
			HANDLEARRAY[1] = hEventFunktionA;						// Event für Funktion A
			HANDLEARRAY[2] = hEventFunktionB;						// Event für Funktion B

			while (true)
			{
				DWORD WaitResult;
				DWORD WaitFor = INFINITE;
				WaitResult = WaitForMultipleObjects(MAX_HANDLES, HANDLEARRAY, false, WaitFor);
				switch (WaitResult)
				{
					case WAIT_OBJECT_0:	// Programmbeendigung eingeleitet
						bTerminationRequested = true;
						ReturnValue = 0;
					break;
					case WAIT_OBJECT_0 + 1:
						FunktionA();	// Aufruf Funktion A
					break;
					case WAIT_OBJECT_0 + 2;
						FunktionB();	// Aufruf Funktion A
					break;
				}
				if (bTerminationRequested || bInternalError)
					break;
			}
		}
		catch (Exception &Ex)
		{
			// Fehler
			bInternalError = true;
			if (ReturnValue == 0)	// in den Funktionen A oder B solltest Du einen eindeutigen Fehlercode setzen
				ReturnValue = -1;	// unbekannter Fehler
		}
	}
	__finally
	{
		// aufräumen
	}
}
//---------------------------------------------------------------------------

Ein paar Erklärungen dazu:
hEventGlobalTerminationRequest ist ein WinAPI Event, dass von der Hauptanwendung ausgelöst wird, wenn das Programm beendet werden soll. Dies ist zwingend notwendig, da durch das WaitForMultipleObjects nicht auf TThread::Terminate() reagiert werden kann. Selbst wenn Du einen sehr kleinen Timeout-Wert einträgst, funktioniert das nicht wirklich. Dieser Event ist in allen Threads identisch (also einmal im der Hauptanwendung erzeugen und als Parameter übergeben.

hEventFunktionA und ...B. Wenn es egal ist, welcher Thread auf den Event reagiert, kannst Du diesen auch global definieren und als Parameter übergeben. Wenn jeder Thread spezifisch angesprochen werden soll, muss er innerhalb des Threads erzeugt werden und am sinnvollsten über eine Funktion abfragbar gemacht werden (hierfür brauchst Du keine CriticalSection, wenn Du das Event im Konstruktor erzeugst, dann finden ja nur lesende Zugriffe statt).

Wenn der Event für FuntkionA oder B ausgelöst werden kann, während der Thread noch arbeitet und Du jeden Aufruf einzeln auswerten mußt, verwende einen Semaphore. Der wird so lange ausgelöst, bis der interne Zähler 0 ist. Praktisch kannst Du damit Events puffern.

Du brauchst den Thread auch nicht 'Suspenden' oder 'Resumen'. So lange kein Event ausgelöst wird, steht der Thread in der WaitForMultipleObjects und verbraucht keine CPU-Zeit.

Un die FunktionA im Thread auszulösen mußt den hEventFunktionA setzen. Sprich überall dort, wor Du FunktionA() aufrufst, musst Du statt dessen SetEvent(hEventFunktionA); aufrufen.

Ich hoffe, das hilft erst einmal. Falls Du Fragen hast...

Das sollte ja so weit richtig sein - oder hab ich da was falsch verstanden?

void __fastcall maindahlia::Execute (void)
 {
  bool again = true;
  int max = 1, WaitResult;
  HANDLE *Handles = new HANDLE[max];
  Handles[0] = &FTerminateRequest;
//restliche Handles hinzufügen
  while (again)
   {
    WaitResult = WaitForMultipleObjects (max, Handles, false, INFINITE);
    switch (WaitResult - WAIT_OBJECT_0)
     {
      case 0:
       again = false;
       break;
      case 1:
// noch machen ^^
       break;
     }
   };
  this->Free();
 };

aber die deklaration wird irgendwo falsch sein: (und wohl auch etwas zu umständlich?)

typedef void __fastcall (__closure *TTerminateRequest) (void);
TTerminateRequest FTerminateRequest;
__property TTerminateRequest Termination = {read = FTerminateRequest};

und zum Beenden würde ich dann das aufrufen:

SetEvent(&Dahlia->Termination);

aber WaitForMultipleObjects wird anscheind dauernd ausgelöst... Aber der Rückgabewert (irgendwas, was mein switch ne drin hat, als falsch sein muss) zeigt, dass da irgendwo noch nen Fehler drin ist...
Wär dir dankbar, wenn du mir mal nen Denkanstoß oder so geben könntest

// Deklaration:
HANDLE hEventGlobalTerminationRequest;
// Erzeugen:
hEventGlobalTerminationRequest = CreateEvent(NULL, true, false, NULL); 
// Löschen:
CloseHandle(hEventGlobalTerminationRequest);

Sollte aber auch mit einem TEvent funktionieren, dann muss aber TEvent::Handle für die WaitFor...-Funktion verwendet werden.

Was Du mit der Funkion erreichen willst, ist mir nicht ganz klar, für einen WinAPI-Event reicht es so:

HANDLE __fastcall TMainForm::GetGlobalTerminationRequestEventHandle()
{
	return hEventGlobalTerminationRequest;
}
//---------------------------------------------------------------------------

Du solltest Dir auf jeden Fall auch mal die Parameter für CreateEvent() ansehen. Für das hEventGlobalTerminationRequest ist es so richtig. Dieses hEventGlobal... erzeuge ich bei mir im MainForm und den Handle übergebe ich dann an alle Threads. Ausgelöst wird es dann innerhalb von TForm::OnClose, oder im Destruktor des Forms. Da das Event nicht automatisch zurückgesetzt wird, wird es von allen Threads behandelt.

MfG

Davon abgesehen, wäre vermutlich ein Tutorial unter Verwendung von Botschaften sinnvoller. Wie auch immer, sowohl die Variante mit Botschaften, als auch die mit Events fallen in den WinAPI-Bereich.

"Threads 2: Arbeiten mit Threads / optimaler Einsatz" mit Sachen wie (viell):

Variablen übergeben / Funktionen kreuz und quer aufrufen / weiß nicht / Optimierungen / Spezielle Eigenheiten von Threads / auf keinen Fall dürfen Sie das machen / blabla

Aber was schreibe ich hier, wenn jemand Zeit hätte würde es das wohl schon geben?!

MfG

Kolumbus schrieb:

"Threads 2: Arbeiten mit Threads / optimaler Einsatz" mit Sachen wie (viell):

Variablen übergeben / Funktionen kreuz und quer aufrufen / weiß nicht / Optimierungen / Spezielle Eigenheiten von Threads / auf keinen Fall dürfen Sie das machen / blabla

Die meisten Sachen die du da sagst sind aber nicht wirklich TThread-spezifisch. Du solltest dir da lieber allgemeine Erläuterungen zum Thema Thread und nebenläufige Programmierung durchlesen. Das ist nämlich erstens Systemspezifisch (WinAPI, Speicher- und Prozeßimplementation allgemein) und zum zweiten sehr umfangreich.

Tutorials sollen im allgemeinen den Einstieg in ein Gebiet erläutern. Aber dieses Thema wäre schon sehr fortgeschritten.

bis bald
akari

akari schrieb:

Tutorials sollen im allgemeinen den Einstieg in ein Gebiet erläutern. ...

Das wusste ich nicht. War da bisher anderer Meinung, da ich schon viele sehr spezielle (tiefgehende) Tut's gesehen hab!??

akari schrieb:

Die meisten Sachen die du da sagst sind aber nicht wirklich TThread-spezifisch.

deswegen ja:

Kolumbus schrieb:

Wo und wie jetzt das spezielle Tut hin müsste kann ich nicht beurteilen...

Gut, hätte ich besser so ausgedrückt: Keine Ahnung, ob ein tiefergehendes Tut zum Thema Thread sinnvoll wäre und wo es hin müsste - ...

akari schrieb:

Du solltest dir ... allgemeine Erläuterungen zum Thema Thread und nebenläufige Programmierung durchlesen. Das ist nämlich ... Systemspezifisch (WinAPI, Speicher- und Prozeßimplementation allgemein)...

Gut das mal so deutlich gelesen zu haben, im Ernst.

MfG

PS: Mal ne persönliche Frage @akari: Wo entspringt eigentlich Dein Nick? hab da so ne Theorie... Ich nehm's nicht persönlich wenn Du darauf nicht antwortest.

Das Problem bei einem weitergehendes Thread-Tutorial hier im BCB-Forum wäre das es in drei Ebenen aufgeteilt sein müßte :
- Die Theorie
- Die Windows-spezifische Umsetzung, Besonderheiten unter Windows, WinAPI
- Die Kapselung der Windows-Thread in der VCl mit TThread.
Und dabei ist der letzte Punkt noch der einfachste und kürzeste.

Zum zweiten Punkt kannst du Nachforschungen im WinAPI-Forum oder in der MSDN anstellen, du wirst merken das da einiges zu lesen ist.
Und zum ersten Punkt kannst du Skripte aus Unis oder Sachbücher lesen.

Mein Nick ist eine Weiterverwendung eines Namens meines alten RPG-Charakters. Ja ich weiß mittlerweile das eigentlich ein weiblicher Name ist

bis bald
akari

Irgendwie stell ich mich gerad bissl doof an ^^
Danke schon mal

Ist diese Vorgehensweise nicht möglich, würde ich eher dazu tendieren, die zu bearbeitenden Objekte in der Anwendung, also z.B. im MainForm zu verwalten und den/die Thread(s) die Objekte holen zu lassen. Der Thread muss dann nur informiert werden, dass es neue Arbeit gibt (Event oder Semaphore). Hierbei muss allerdings ein Zugriffsschutz verwendet werden. Möglicherweise reicht dazu eine TThreadList aus.

um die Sache zu vervollständigen: Da ich meine Nick's immer aus dem real-life beziehe, hatte ich ne andere Theorie: akari hatte als kleiner Lausebengel ne Spielekonsole und konnte deren Namen nicht korrekt aussprechen. Und so wurde schon in frühen Jahren aus einem allseits bekannten Atari der im Forum bekannte "akari"...
Das mit dem Mädchennamen wusste ich übrigens auch nicht, aber jetzt wo Du's so sagst...

MfG

Nein ich hatte nie einen Atari.
Das reicht aber jetzt an Offtopic.

bis bald
akari

Danke schon mal