Worker-Threads mit Methoden?

Hallo...

ich möchte in meinem Code eine elegante Lösung bzgl. Worker-Threads realisieren. Das Problem ist, dass ein Worker-Thread immer durch eine Funktion realisiert wird, welche keinen Zugriff auf die Klassenelemente der Erzeugerklasse besitzt. Deshalb muss man die oftmals globale oder modulweite Variablen deklarieren, wenn mehrere Threads auf den gleichen Daten arbeiten. Und wenn man einen Zeiger auf die Erzeugerklasse in den LPVOID-Parameter des Threads steckt, hat man nur Zugriffe auf die public-Methoden/Attribute....

Gibt es irgendwie eine "saubere" Möglichkeit, die Funktion eines Worker-Threads "in den Klassenkontext" zu erheben?

Danke...

Cosmixx

Hallo,
wenn ich Dich richtig verstanden habe, willst Du einen non-static Worker-Thread:

Thread aufrufen:

m_pThread=AfxBeginThread(CallThread, LPVOID(this));

static-Thread-Methode, ruft eigentlichen Worker-Thread auf:

UINT CallThread(LPVOID pParam)
{
  ((DeinDlg *)pParam)->WorkerThread();
  return(0);
}

Hilft Dir das?

MuehBln

also das meintest Du wohl nicht, oder...?

Da WorkerThreads zur Klasse gesehen "externe" Methoden sind, kann ich auch nur die public-Elemente ansprechen.

Will man sie direkt in den Kontext heben, um zumindest auf protected-Elemente zugreifen zu können, müsste (Theorie) der Thread von WinThread und der Klasse selbst abgeleitet sein - was also Mehrfachvererbung bedeuten würde.

Cosmixx schrieb:

Hallo,
wenn ich Dich richtig verstanden habe, willst Du einen non-static Worker-Thread:

Thread aufrufen:
m_pThread=AfxBeginThread(CallThread, LPVOID(this));
static-Thread-Methode, ruft eigentlichen Worker-Thread auf:
UINT CallThread(LPVOID pParam)
{
  ((DeinDlg *)pParam)->WorkerThread();
  return(0);
}
Hilft Dir das?

Das ist ja genau mein Problem: Die Methode "WorkerThread()" muss dann "public" sein. Genau das will ich verhindern... nur wie?

MuehBln schrieb:

also das meintest Du wohl nicht, oder...?

Da WorkerThreads zur Klasse gesehen "externe" Methoden sind, kann ich auch nur die public-Elemente ansprechen.

Will man sie direkt in den Kontext heben, um zumindest auf protected-Elemente zugreifen zu können, müsste (Theorie) der Thread von WinThread und der Klasse selbst abgeleitet sein - was also Mehrfachvererbung bedeuten würde.

Hmm... irgendwie leuchtet das ein... ich wollte mich ein wenig um die MFC-Threads drücken...

Ich habe jetzt eine andere Sache rausgefunden, die aber auch nicht so doll ist: Ich kann eine statische Methode als Worker-Thread laufen lassen... Dann habe ich sogar zugriff auf Klassenelemente. Dummerweise geht das aber nicht mit dynamischen Objekten wie z.B. CList, CString usw... also auch doof...
Hmm... so was dummes aber auch...

siehe: http://www.henkessoft.de/mfc_einsteigerbuch_kapitel17.htm