3. Zugriffssynchronisation zwischen Threads

Zugriffssynchronisation zwischen Threads

  • ?

    TheTester schrieb:

    das einfachste für windows wäre die critical section ist von der art her wie ein mutex objekt nur irgendwie einfacher 😉 und auch schneller

    Einfacher? Schneller? Kannst du das auch sachlich begründen oder wolltest du nur mal wieder rumprollen?

    0
  • T

    nö hat ich nur gelesen einmal in der opengl superbible und dann im petzold, ach warte ich glaub das selbe stand sogar in der msdn...

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/critical_section_objects.asp

    ach ja und wenn du jetzt drauf rumhacken magst das mutex objekte doch eigentlich was anderes sind, ja hast recht sie sind viel komplexer und bieten mehr möglichkeiten, ich persönlich hab eigentlich nur CS objekte benötigt da ich bis jetzt nur threads von einem prozess synchronisieren musste

    bye

    tt

    0
  • S

    Ich wuerde einfach nach einer Library suchen die Threads plattforumunabhaengig kapselt.

    Fuer C kenne ich leider keine - aber ich verschieb es mal nach "Rund um"

    0
  • ?

    @TheTester: Ja, und Philip Morris schreibt in seinen Prospekten auch, dass Zigaretten nicht sooo ungesund sind - da muß es ja stimmen! Also dürfte die MSDN auch recht habe, wenn sie behauptet, unter Windows geht es schneller und einfacher.

    Nur komisch: Unter Linux brauche in für die Initialisierung lediglich einen Funktionsaufruf mit ein paar einfachen Parametern - unter Windows muß ich zusätzlich schon eine dümmliche Struktur mit anlegen (dereneinzig sinnvoller Inhalt ein boolean-Member ist - als ob man sowas nicht auch mit einem Flag erschlagen könnte).

    Abfragen eines Lock-States sind unter Linux auch ganz simpel: ein einziger Funktionsaufruf. Unter Windows muss ich die diversen Rückgabewerte (deren Zustände mich gar nicht interessieren) trotzdem überprüfen, weil ich nur bei einem einzigen den Mutex unlocken darf.

    Has du also sonst noch was rumzutrollen?

    0
  • P

    @Barton:
    boost (www.boost.org) hat eine OS-Übergreifende Threading-Bibliothek. Wenn du also mehrere OS unterstützen möchtest, ist es evtl. einfacher, eine solche Bibliothek zu verwenden.

    Übrigens ist bereits das ListLocked++ selbst nicht threadsicher. Vielleicht mal ein, zwei Tutorials reinziehen (z.B.http://www.codeproject.com/threads/sync.asp - nicht sodnerlich, aber ein Anfang)

    @Trolljäger: Whoaaah! Eh du mit deinem großen Trolltotschießgewehr runfuchtelst, mach bitte erstmal deine Hausaufgaben. Das Ding ist gefährlich.

    0
  • ?

    peterchen schrieb:

    @Trolljäger: Whoaaah! Eh du mit deinem großen Trolltotschießgewehr runfuchtelst, mach bitte erstmal deine Hausaufgaben.

    Ja bitte? Was war an meinen Aussagen falsch? Kannst du dazu auch was sagen oder gibst du hier auch bloß an?

    Ich kann dir aber sagen, was bei http://www.codeproject.com/threads/sync.asp falsch ist:

    WaitForSingleObject( hMutex, INFINITE );
for ( i = 0; i < 5; i++ ) a[ i ] = num;
ReleaseMutex( hMutex );

    Das ist laut MSDN ohne Abfrage des Returnwertes von WaitForSingleObject() nämlich schlicht nicht zulässig (siehe http://msdn.microsoft.com/library/en-us/dllproc/base/using_mutex_objects.asp). Also mach erst mal deine Hausaufgaben, bevor du die Leute hier falsch informierst.

    0
  • T

    trolljäger
    **********

    Das ist laut MSDN ohne Abfrage des Returnwertes von WaitForSingleObject()
    nämlich schlicht nicht zulässig

    wo steht das auf der verlinkten seite?

    es stellt sich doch eher die frage ob das so gut ist threads, ohne jegliches error handling, zu synchronisieren, weil es könnte ja passieren das...usw.

    tschööö

    tt

    PS: lasst uns nicht streiten 🙂

    0
  • P

    Das ist laut MSDN ohne Abfrage des Returnwertes von WaitForSingleObject() nämlich schlicht nicht zulässig

    Deswegen hab ich ja gesagt "nicht sonderlich".

    Ja bitte? Was war an meinen Aussagen falsch?

    a) SEUCRITY_ATTRIBUTES ist keine Sinnlose Strukture
    b) in den allermeisten Fällen genügt hier ein NULL-Zeiger
    c) In den meisten Fällen, wo der nicht genügt, genügt eine einmal initialisierte globale struktur
    d) SECURITY_ATTRIBUTES hat zwei Member
    e) ist ja toll das es unter Linux weder ungültige Handles gibt
    f) noch toller ist allerdings, das man den Mutex imemr bekommt - warte, man kann keien Timeout angeben, richtig?
    g) Testers Aussagen bzgl. Mutex vs. Critical Section (unter Windows) sind korrekt - Critical Sections sind einfacher zu verwenden, aber auf einen prozeß beschränkt
    h) Critical Sections unter Windows kommen der oben angegebenen API schon näher.

    Happy crunching. Troll.

    0
  • ?

    > a) SEUCRITY_ATTRIBUTES ist keine Sinnlose Strukture

    Nein, aber für das wenige bißchen Inhalt eine eigene Struktur zu spendieren ist schlichtweg übertrieben.

    > b) in den allermeisten Fällen genügt hier ein NULL-Zeiger
    > c) In den meisten Fällen, wo der nicht genügt, genügt eine einmal initialisierte globale struktur

    Schön. Wie hast du das ermittelt? Hast du alle Entwickler gefragt? Und "globale Struktur" klingt ganz toll. Du bist Großmeister in Softwaredesign, gell? LOL!

    > d) SECURITY_ATTRIBUTES hat zwei Member

    Falsch.

    > e) ist ja toll das es unter Linux weder ungültige Handles gibt
    > f) noch toller ist allerdings, das man den Mutex imemr bekommt - warte, man kann keien Timeout angeben, richtig?

    Falsch. Ich empfehle "apropos mutex" und anschließend "man pthread_mutex_..."

    > g) Testers Aussagen bzgl. Mutex vs. Critical Section (unter Windows) sind korrekt - Critical Sections sind einfacher zu verwenden, aber auf einen prozeß beschränkt

    Und damit für die meisten Fälle vermutlich nicht zu gebrauchen!?

    > Troll

    Auweia, das sagt der richtige. Mächtig peinlich, wie weit du dich mit deinem Halbwissen hier aus dem Fenster hängst.

    0
  • P

    a-c) vielleicht weil ich damit arbeite? Weil ich die Anwendungsfälle kenne, unter denen man SECURITY_ATTRIBUTES braucht?
    d) Oh! Oh! Ich hab nLengh vergessen! ich schlimmer ich...

    Ob du die Struktur "sinnvoll" findest oder nicht, ist deine Sache. Und ob CRITICAL_SECTION "nutzlos" ist, überlaß bitte denen, die es verwenden.

    Was ist gegen eine globale SECURITY_ATTRIBUTES(size,NULL,true) einzuwenden? Wenn du mir sagst "das ist niicht OOP" nehm' ich das TROLL zurück und lach ich dich aus.

    Das beste was ich für zum thema pthread_ gefunden habe ist http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html. Ich seh noch nicht was daran so vie toller ist, und wieso man da keine Fehlercodes testen muß, aber naja gut - du wirst das schon wissen.

    0
  • ?

    peterchen schrieb:

    Ich seh noch nicht was daran so vie toller ist, und wieso man da keine Fehlercodes testen muß, aber naja gut - du wirst das schon wissen.

    1. "So viel toller/schlechter" stammt nicht von mir - diese Trollaussage darfst du TheTester an den kopf werfen.

    2. Ich habe nie behauptet, dass man keine Fehlercodes testen muß - man kann es sich aber beim lock ersparen, weil das unlock nicht so kritisch ist und returnwert-abhängig behandelt werden muß.

    > Wenn du mir sagst "das ist niicht OOP" nehm' ich das TROLL zurück und lach
    > ich dich aus.

    Wie dumm muß man eigentlich sein, um solche Sachen zu erfinden? Seit wann ist Windows in C++ geschrieben? Hast du es schon mal mit nachdenken probiert, bevor du postest?

    0
  • T

    ähmm...ich glaube hier werden ziemlich inhaltliche dinge verdreht

    1. "So viel toller/schlechter" stammt nicht von mir - diese Trollaussage
    darfst du TheTester an den kopf werfen.

    hab ich nie behauptet, weiterhin hab ich nie etwas über pthreads geschrieben...

    das worauf du dich sicher beziehst, war meine antwort auf deinen post zur msdn 🙂 auf seite 1

    tschöö

    tt

    0
  • P

    @Trolljäger: Pfft.

    0
Anmelden zum Antworten