4. threads anhand eines hallo world progs :D

threads anhand eines hallo world progs :D

  • C

    Doch Troll!

    vista schrieb:

    nix troll!
    warum _binginthreadex?

    lol, Siehe ➡ http://www.microsoft.com/msj/1099/win32/win321099.aspx

    vista schrieb:

    was soll das staic_cast bzw. reinterpret_cast geraffel?

    Das sind C++ Casts, die benutze ich immer. Diese sind, meiner Meinung nach, übersichtlicher und sicherer.

    vista schrieb:

    in die critical section gehört das 'cout' eingepackt, nicht das abfragen der variablen...

    Natürlich muss der Zugriff auf die Variable gelockt werden...oha.

    0
  • V

    CodeFinder schrieb:

    vista schrieb:

    nix troll!
    warum _binginthreadex?

    lol, Siehe ➡ http://www.microsoft.com/msj/1099/win32/win321099.aspx

    ich sagte nicht, man solle 'CreateThread' nehmen. '_beginthread' ohne EX hätte gereicht.

    CodeFinder schrieb:

    vista schrieb:

    was soll das staic_cast bzw. reinterpret_cast geraffel?

    Das sind C++ Casts, die benutze ich immer. Diese sind, meiner Meinung nach, übersichtlicher und sicherer.

    typischer anfänger-irrtum!
    dazu ein dickes mega-*lol*

    CodeFinder schrieb:

    vista schrieb:

    in die critical section gehört das 'cout' eingepackt, nicht das abfragen der variablen...

    Natürlich muss der Zugriff auf die Variable gelockt werden...oha.

    [/quote]
    in dem fall nicht, es wird nur zwichen true und false unterschieden, ein thread liest nur, der andere schreibt, du brauchst keinen lock dafür.
    aber das 'cout' muss synchronisiert werden ⚠

    0
  • C

    vista schrieb:

    ich sagte nicht, man solle 'CreateThread' nehmen. '_beginthread' ohne EX hätte gereicht.

    _beginthread lößt das in dem Artikel beschriebene Problem aber nicht.

    vista schrieb:

    typischer anfänger-irrtum!
    dazu ein dickes mega-*lol*

    Sehr aufschlussreich Deine Aussage... . Naja dazu fällt mir irgendwie grad nicht viel zu ein, liegt wohl am Gehalt dieses Statements. Falls Dir Vererbung und RTTI bekannt sind, solltest Du eigentlich wissen wovon ich rede.

    vista schrieb:

    in dem fall nicht, es wird nur zwichen true und false unterschieden

    LOL...'es wird nur zwischen true und false unterschieden'... *grinz* ... . Ich weiß grad nicht was ich sagen soll 😃 😃 ...

    0
  • V

    CodeFinder schrieb:

    _beginthread lößt das in dem Artikel beschriebene Problem aber nicht.

    ein 'multithreading' hello-world programm aber schon...

    CodeFinder schrieb:

    Falls Dir Vererbung und RTTI bekannt sind, solltest Du eigentlich wissen wovon ich rede.

    natürlich, dein code macht ja von RTTI und vererbung ausgiebigen gebrauch 😃

    CodeFinder schrieb:

    LOL...'es wird nur zwischen true und false unterschieden'... *grinz* ... . Ich weiß grad nicht was ich sagen soll 😃 😃 ...

    ...konnte ich mir denken 😡
    nochmal zum mitschreiben:
    der main-thread schreibt setzt die variable 'data.dwAbortThread' auf FALSE um den thread zu beenden. der thread kopiert diese variable sinnloserweise noch in eine lokale variable, aber egal, entscheidend ist das TRUE oder FALSE, also nicht-0 oder 0. dafür reicht es vollkommen aus, wenn sich nur ein bit verändert hat. weil der thread nur lesend darauf zugreift und 0 oder nicht-0 unterscheiden muss (du prüfst ja nicht auf 0x1234 oder 0xabcdef, was durchaus einen unterschied machen würde) brauchst du dafür keinen lock.
    aber das 'cout' muss einen lock bekommen, denn c++'s std:: ist nicht 'multithreading aware'!!!
    ich empfehle dir dringend ein paar (win32) threading tuts durchzuarbeiten!

    btw: ...und threadprocs für _beginthreadex und _beginthread haben als aufrufkonvention nicht __stdcall sondern __cdecl, aber ich weiss, das würde dich jetzt echt überfordern... 😃

    0
  • ?

    2 kämpfende Fredchen

    0
  • V

    KennerDerTierchen schrieb:

    2 kämpfende Fredchen

    ääääy, pssst!
    😉

    0
  • C

    vista schrieb:

    ein 'multithreading' hello-world programm aber schon...

    Nö.

    vista schrieb:

    natürlich, dein code macht ja von RTTI und vererbung ausgiebigen gebrauch 😃

    Nein, aber es geht ums Prinzip.

    vista schrieb:

    btw: ...und threadprocs für _beginthreadex und _beginthread haben als aufrufkonvention nicht __stdcall sondern __cdecl, aber ich weiss, das würde dich jetzt echt überfordern... 😃

    Nein das ist falsch. Siehe: http://msdn2.microsoft.com/en-us/library/kdzttdcb(vs.71).aspx
    Bei _beginthread ist es __cdecl, bei _beginthreadex ist es __stdcall! 😉 :

    MSDN schrieb:

    uintptr_t _beginthread( 
   void(    __cdecl    *start_address )( void * ),
   unsigned stack_size,
   void *arglist 
);
uintptr_t _beginthreadex( 
   void *security,
   unsigned stack_size,
   unsigned (    __stdcall    *start_address )( void * ),
   void *arglist,
   unsigned initflag,
   unsigned *thrdaddr 
);

    Auf den Text dazwischen hatte ich kein Bock, der war mir zu lang :p ^^.

    EDIT: Hab kein Bock mehr mich zu kebbeln^^, hören wir auf ? 😉

    0
  • V

    CodeFinder schrieb:

    vista schrieb:

    btw: ...und threadprocs für _beginthreadex und _beginthread haben als aufrufkonvention nicht __stdcall sondern __cdecl, aber ich weiss, das würde dich jetzt echt überfordern... 😃

    Nein das ist falsch. Siehe: http://msdn2.microsoft.com/en-us/library/kdzttdcb(vs.71).aspx
    Bei _beginthread ist es __cdecl, bei _beginthreadex ist es __stdcall! 😉 :

    gut, du hast recht, asche über mein haupt 😮
    aber warum m$ sowas macht steht wohl in den sternen...

    CodeFinder schrieb:

    Auf den Text dazwischen hatte ich kein Bock, der war mir zu lang :p ^^.

    schade eigentlich...

    0
  • C

    CodeFinder schrieb:

    EDIT: Hab kein Bock mehr mich zu kebbeln^^, hören wir auf ? 😉

    Wie siehts damit aus 😉 ?

    0
  • V

    CodeFinder schrieb:

    CodeFinder schrieb:

    EDIT: Hab kein Bock mehr mich zu kebbeln^^, hören wir auf ? 😉

    Wie siehts damit aus 😉 ?

    also ich finde wir sollten das ausdiskutieren.
    der OP hat doch bestimmt auch was davon...
    🙂

    0
  • C

    "der main-thread schreibt setzt die variable 'data.dwAbortThread' auf FALSE um den thread zu beenden. der thread kopiert diese variable sinnloserweise noch in eine lokale variable, aber egal, entscheidend ist das TRUE oder FALSE, also nicht-0 oder 0. dafür reicht es vollkommen aus, wenn sich nur ein bit verändert hat. weil der thread nur lesend darauf zugreift und 0 oder nicht-0 unterscheiden muss (du prüfst ja nicht auf 0x1234 oder 0xabcdef, was durchaus einen unterschied machen würde) brauchst du dafür keinen lock.
    aber das 'cout' muss einen lock bekommen, denn c++'s std:: ist nicht 'multithreading aware'!!!
    ich empfehle dir dringend ein paar (win32) threading tuts durchzuarbeiten! "
    Jop, hast Recht, okay ?

    0
  • V

    CodeFinder schrieb:

    Jop, hast Recht, okay ?

    nein, so funktioniert das nicht!
    du musst begründen warum du das so und so gemacht hast und mir sagen, dass ich mist schreibe...
    🙂

    0
Anmelden zum Antworten