So, ich habe n map format das beim ersten mal laden relativ lange braucht und nicht nur aus diesem grund brauche ich ne möglichkeit mir den status des ladevorgangs abzufragen und anzuzeigen. ich löse das über multi-threading. auch wenn es sich bei nem progress-wert (der abzufragen ist) nur um einen float handelt will ich auf nummer sicher gehen und diese shared-resource (da von beiden threads genutzt a) schreibt b) ließt ) absichern.
nach n bissle recherche bin ich auf unzählige möglichkeiten gestoßen, die so wie ich es verstanden habe alle den selben zweck erfüllen, nämlich entwerder den status signaled oder eben nicht zu haben und dem entsprechend zugriff gewähren wenn angefordert.

LANGE Rede kurze Frage: wo ist der unterscheid bei den mannigfaltigen methoden, speziell: Mutex und CriticalSection
edit: und... was könnt ihr mir über Semaphore sagen ?!

_________________
www.extrawurst.org

Critical Section sagt mir nichts.

Semaphore und Mutex kommen in SDL vor, daher kann ich sie dir erkären

Der Unterschied ist einfach, dass ein Mutex in Boolean, eine Semaphore ein Integer ist.
Bei einem Mutex kann nur ein Thread auf den Wert zugreifen.
Bei einer Semaphore definierst du wieviele Threads auf den Wert gleichzeitig zugreifen dürfen (für Drücker etc nützlich).

Tzä *hehe* das mach ich anders, ohne Threads, tu in deiner Ladeschleife einfach die Nachrichtenabarbeitung des Windowsfensters aufrufen. Du musst nur die Close-Nachricht während dieses Vorgangs abfangen, ansonsten passiert was unschönes. Ist bei einer Ladeanzeige, wo der Nutzer nicht groß interagieren soll einfacher zu implementieren als erst mit Multithreading anzufangen.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

das es da auch andere art und weisen gibt das zu implementieren weiß ich, aber ich brauch multithreding eh noch und getz hab ich es schon in schmucke klassen gewrappt...
also: "was du heute kannst besorgen das verschiebe nicht auf morgen"

also wer kann mir nun n bissle genauer die unterschiede erklären ? das was ionos als mutex erklärt hatte ich immer gedacht wäre eine critical section und das was er als semaphore beschrieb wiederum dachte ich wäre n mutex...

_________________
www.extrawurst.org

In eine Critical Section kann man nur einmal eintreten, d.h. wenn Du irgendwo critSect.Enter stehen hast, warten alle anderen Threads solange, bis der Tthread am CritSect.Leave vorbeigekommen ist. Damit das klappt, muss die Critical Section allerdings eine globale Variable sein, z.B.: im Initialization Abschnitt kreiert und im finalization Abschnitt wieder freigegeben oder als member einer Klasse, die nur einmal instantiiert werden kann.
Damit kann man quasi Codeabschnitte threadsicher machen, wei z.B.: das Schreiben Deiner Fortschrittsvariable oder Dateizugriffe oder Ringpuffer oder oder oder

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Ein Kritischer Abschnitt (critical section) ist kein Objekt wie die beiden anderen Dinger, sondern ein Stück code welcher gesichert werden muss. Bei dir besteht der Kritische Abschnitt also nur aus der Wertzuweisung welche den Fortschritt speichert.

Mutex und Semphore sind prinzipiell das selbe. Aber wie ionis bereits geschrieben hat, sind Semaphoren die allgemeineren sperren, da sie auch mehrere Instanzen eines Betriebsmittels überwachen können (Wenn du z.B. Drucker verteilst, kannst du mit einer Semaphore regeln, dass nur so viele Threads Drucker anforndern können, wie es Drucker gibt).

Im grunde genommen, must du also nur deinen Kritischen Abschnitt mittels Semaphoren (hier mit MuTex-Semaphoren) absichern, und das wars. Wenn du den Wert ausließt, manipulierst und dann erst wieder zurückschreibst, gehört das alles in den Kritischen Abschnitt, ansonsten hast du's mit "race conditions" zu tun. Die führen gern mal zu einem "Lost Update". Fachchinesisch? Ja! Du findest das sicherlich auch bei Wikipedia erklärt oder auf Seiten die sich mit Betriebssystemprogrammeirung befassen. Zu empfehlen ist auch das Buch von Andrew S. Tannenbaum : "Moderne Betriebssysteme".

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich weiß jetzt nicht genau wie sich das mit Floats verhält aber die Zuweisung eines Ints (außer 64er) sind Elementare Operationen. Wenn ich mich mit dem Namen nicht voll vertue. Diese Operationen sind so klein, dass sie vom Betriebssystem nicht unterbrochen werden. In deinem speziellen Fall hast du nur die Übergabe eines einzelnen Wertes und diese Zuweisung wird nicht unterbrochen. Also müsstest du diese Stelle normal auch nicht synchronisieren lassen. Besser es ist es aber alle mal, weil es schnell mal mehr werden kann und dann fehlts.

Flash: Mutexe sind meines Wissens nach aus Instanzübergreifend. Oder können es zu mindest sein. Werden auch häufig dafür verwendet wenn man nur eine Instanz einer Anwendung haben will.

Nach Möglichkeit solltest du aber deine Vortschritsanzeige nicht zu genau gestalten. Bei einer 300 pixeligen Anzeige erkennt man die 0.02% Unterschied nämlich nicht mehr und das Einzige was du dir sonst aufheilst ist der Overhead durch die massige Synchronisiererei. Wenn ich dem Gehört glauben darf ist die Critical Section wohl recht teuer. Also wie überall sollte man nur das Nötigste machen.

Es gibt auch noch SpinLockLoops. Die müssten so oder so ähnlich gehen:


Nur um die Qual der Wahl noch etwas größer zu machen ^^

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Pfui! Das ist ja ne dezentrale Lösung mit "bussy waiting"! Du eckelst dich auch vor garnix.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Busy Waiting sieht doch so aus:

Mit dem Sleep heissts irgendwie anders. Weis nimmer wie

Hmmm...stimmt...wobei das definition ist wie wait implementiert ist

_________________
Blog: kevin-fleischer.de und fbaingermany.com

leider ist es mit floats eben nicht sicher, aber auch so wollte ich mich mit dem thema jetzt schonmal in dieser entwas kleinen form befassen damit ich ne bessere vorstellung bekomme wo mir das noch nützen kann (meine multithreading allg.) z.b. physik,netzwerk usw..

_________________
www.extrawurst.org

floats sind nicht sicher? an sich ist dass nur eine assembleranweisung, sollte sich also zumindest auf neueren Prozessoren, die auch ohne fwait auskommen atomar verhalten. Aber ansonsten schaden die angesprochenen Möglichkeiten natürlich auch nicht, solange nicht zuviel in kritischen Bereichen abläuft.

meine aussage stützt sich auf "windows programming" von pertzold in der ?.auflage, is schon etwas betagt das buch und ich weiß absolut nich ab welcher CPU-Generation das nicht mehr so ist, wenn ihr mir das sagen würdet, wär ich euch echt dankbar!

_________________
www.extrawurst.org

Hm bei nem float 32 bit würd ich sagen, da die Register der modernen CPUs min. 32 bit register haben, dass da nix getrennt wird.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup