THREADID ThreadId_;

void foo(){

   DATA *p= IRGENDWAS;
   int code = thread_create(Thread::EntryPoint, (void*) p, & ThreadId_);
   //(A)
};

void * EntryPoint(void * pthis){

   DATA * pt = (DATA*)pthis;

  //(B)

}

Deine Frage ist doch, ob nach der "create_thread"-Funktion p schon mit ordentlichen Daten gefüllt wurde? Weil nein, das ist nicht der Fall. Es könnte z.B. sein, dass die create_thread-Funktion ausgeführt wird, der neue Thread gestartet wird aber noch keine Prozessorlaufzeit bekommt und deine foo-Funktion fortfährt; dann wäre der Inhalt von p unverändert.

Ich denke du hast zwei Möglichkeiten: Entweder du machst dir eine bool-Variable in DATA rein. Die setzt du in der EntryPoint-Funktion, nachdem du den Rest von DATA gefüllt hast.
Oder du machst folgendes:

struct ThreadParameterData
{
    DATA* p;
    bool init;
};

void foo(){

   DATA *p= IRGENDWAS;
   ThreadParameterData* d = new ThreadParameterData;
   d->p = p;
   d->init = false;
   int code = thread_create(Thread::EntryPoint, (void*) ThreadParameterData, & ThreadId_);
   while ( ! d->init )
       ;
   //(A)
};

void * EntryPoint(void * pthis){

    ThreadParameterData* pd = (ThreadParameterData*)pthis;
    // pd->p füllen
    pd->init = true;

  //(B)

}

@badestrand: hallabusa sagt das eine kope des pointer aufm stack gespeicehrt wird, d.h. wenn der theadentry funktion noch nicht gestartet werden kann, ist ja diekopie trozdem noch da oder irre ich mich... Aber trozdem eine gute idee deine möglichkeit;)

Na, sowas macht man aber besser mit einer Condition als mit einem Busy-Loop, oder?

@Boris:
Ich glaube (glaube, weil ich nicht ganz sicher bin dass wir dasselbe verstehen was Du meinst) das eine hat mit dem anderen wenig zu tun. In dem Moment, wo Du create_thread aufrufst, wird das Argument auf den Stack dieser Funktion kopiert, welche den Thread startet und in dem Thread die Funktion (wieder mit dem Argument auf dem Stack) durchläuft. Das ist bis hierhin noch "normales C(++)" - bei der Betrachtung von Lebenszeiten wird jetzt wichtig, worauf ein dort übergebener Zeiger zeigt, nicht der Zeiger selbst.

Badestrand wollte Dir glaube ich nur eine Möglichkeit aufzeigen, wie man von der Thread-Funktion aus an den Thread-Ersteller eine Nachricht schicken kann (wobei man das imho lieber über Conditions lösen sollte).

Was ich eigentlich wollte:
Mylord, was meint Er mit Conditions?

Was ich eigentlich wollte:
Mylord, was meint Er mit Conditions?

Conditions ist ein Threadkontrollmechanismus, der bedingtes Warten ermöglicht. Kurz und bündig (es steckt mehr dahinter, aber das würde zu weit führen) kannst Du damit in Verbindung mit einem Mutex einen oder mehrere Threads in einen Wartezustand schicken, bis ein anderer Threads ihn/sie wieder aufweckt. In Deinem Beispiel sähe das etwa wie folgt aus (Achtung Pseudocode):

void foo(){
   Condition cond;

   cond.lock();
   int code = thread_create(Thread::EntryPoint, (void*) &cond, & ThreadId_);
   cond.unlockAndWait();
   //(A)
};

void * EntryPoint(void * pthis) {
    Condition* cond = (Condition*) pthis;

    cond->lock();
    // mache was, worauf (A) warten muss
    cond->wake_up();
    cond->unlock();
    //(B)
    cond = 0; // FESTLEGUNG: nachdem der Erzeuger aufgeweckt wurde, verschwindet cond aus dem Leben (lokale Variable in (A)) und darf hier nicht mehr benutzt werden!
}

(1) in funktion foo() zeigt p auf ein Objekt im speicher

(2) bei createthread wird eine kopie des zeigers im stack erstellt.

(3) foo wird beendet, aber die kopie im stack von createtrhead ist noch da!

d.h. die entrytrhread funktion hat aufjedenfall einen zeiger auf das objket, obwohl foo schon beendet wurde..

oder seh ich das falsch?

ja gut..

(1) in funktion foo() zeigt p auf ein Objekt im speicher

(2) bei createthread wird eine kopie des zeigers im stack erstellt.

(3) foo wird beendet, aber die kopie im stack von createtrhead ist noch da!

d.h. die entrytrhread funktion hat aufjedenfall einen zeiger auf das objket, obwohl foo schon beendet wurde..

oder seh ich das falsch?

(3) Stimmt nicht ganz. Die Kopie liegt nicht mehr auf dem Stack, sondern irgendwo wo sie von thread_create gespeichert wurde. Der Stack wird ja nach dem Beenden der Funktion wieder abgeräumt. Du brauchst aber keine Conditions, weil du ja keinen Pointer oder Referenz auf p übergibst, sondern der Wert kopiert wird. Du könntest sogar garnichts machen, weil die Lebenszeit von p garnichts mit der von der Kopie, die beim Funktionsaufruf erzeugt, wird zu tun hat.

(3) Stimmt nicht ganz. Die Kopie liegt nicht mehr auf dem Stack, sondern irgendwo wo sie von thread_create gespeichert wurde.

Stimmt auch nicht ganz, die Parameter der Funktion EntryPoint liegen natürlich auch wieder auf dem Callstack, nur dass dieser der Stack des neuen Threads ist (den meinte ich zuvor auch) und nicht der Stack des Erzeugers.

EDIT: Ok, rein technisch stimmt der Satz, da der Stack des neuen Thread auch "irgendwo" liegt

hallobalusa schrieb:

(3) Stimmt nicht ganz. Die Kopie liegt nicht mehr auf dem Stack, sondern irgendwo wo sie von thread_create gespeichert wurde.

Stimmt auch nicht ganz, die Parameter der Funktion EntryPoint liegen natürlich auch wieder auf dem Callstack, nur dass dieser der Stack des neuen Threads ist (den meinte ich zuvor auch) und nicht der Stack des Erzeugers.

EDIT: Ok, rein technisch stimmt der Satz, da der Stack des neuen Thread auch "irgendwo" liegt

Genau deshalb hab ich irgendwo geschrieben. Es muss aber auch nicht der Callstack von EntryPoint sein. thread_create kann ja schon wieder beendet sein, vor der andere Thread gestartet wurde. Der Wert könnte irgendwo im Stack oder Heap des Schedulers oder sonst wo sein. Keine Ahnung was das OS da genau macht.

BorisDieKlinge schrieb:

ok Jungs... also muss ich jetzt ne condition einbauen oder net??

nein, nicht für p.