001
05.05.2004, 16:02 Uhr
RHBaum
|
Der Klassische C++ weg ist halt ... ein Objekt (eine instanz einer Klasse die im haupthread erstellt wurde) erstellt einen Thread.
der erstellte Thread dabei ist halt eine Statischer Nebenpfad (threadproc, statisch) der seinen Ersteller nicht kennt. Der Ersteller wiederum kann nur auf grundlegende Threadfunktionalitaet ueber das BS den thread beeinflussen, uebr das Threadhandle (was er beim erstellen des Threads bekommt).
Um trotzdem was mit dem Thread anfangen zu koennen, uebergibt der ersteller des Threades einen Zeiger (void * ) an die statische Threadproc. Meist nen Verweis (zeiger) auf sich selbst ! Die threadproc castet den dann in den entsprechenden typ und hat somit zugriff auf die daten des aufrufers (da die threadproc meist im selben Kontext wie das Object laeuft, also die threadproc statische memberfunktion der Klasse ist, hat sie auch zugriff auf private members).
Das ganze geht auch procedural, ohne die klassen ... ist aber dann ned so schoen geordnet. Der voidzeiger muss auch nicht immer nen zeiger auf das erstellerobjekt sein, sondern kann auch nen proxy oder nen anderweitig geartetes Kommunikationsobject sein ....
Zu deiner Frage ....
| Zitat: |
geht das auch umgekehrt?
|
prinzipiell ja ....
Das Object das die threadproc bekommt, braucht nur registrierfunktionen haben, wo die threadproc eigene Members registrieren kann. damit bekommen irgend ein Member oder die Instanz selber nen verweis auf die Variablen des Nebenthreads und kann drauf zugreifen ! Achtung THREADSICHERHEIT !!!
Bleibt nur noch die Frage nach dem Sinn !  und den Konsequenzen !
Ueblich ist eigentlich das der nebenthread nur variablen hat, die er selbst zur verwaltung braucht. Alles wo geshared drauf zugegriffen werden soll, kannst doch in den Haupthread legen ... warum im Nebenthread ???
Und die Konsequenz :
Beim runterfahren musst tierisch aufpassen ! Du signaliseirts normalerweise deiner Threadproc das sie aufhoeren soll vom haupthtread aus.... und gehst ind den Wartezustand bis die threadproc down ist ... in der Zeit ist fuer den Haupthread (kein problem der wartet eh) und aber auch alle anderen nebenthreads der status der Variablen im runterfahrenden Nebenthread unbestimmt. Wenn der Zugriff korrekt abgesichert ist, ist der Zugriff eh geloggt ... aber normal sollten die Critical sections da liegen, wo auch die zu schutzenden variablen sind, also im nebenthread ... und beendet der sich, fliegen auch die Critical sections weg, was katastrophal ist wenn da noch wer auf den lock wartet.
Sprich es zwar moeglich, aber besser/einfacher ists gesharte Variablen im Haupthread zu halten, weil da mehr kontrollle ueber die Threadverlauefe hast, und dein Haupthread definitiv der letzte ist, der sich beendet ... wenn das Program normal beendet :p
Wenn Du ziemlich extensiv grosse Datenbereiche mit eigenstaendigen Verhalten (Threads) brauchst, die gegeneinander recht gut abgeschottet sein sollten und und ueber schnittstellen miteinander kommunizieren, solltes eher unterschiedliche Prozesse aufziehen.
Ciao ...
Dieser Post wurde am 05.05.2004 um 16:08 Uhr von RHBaum editiert. |
