Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Atomare Variablen?

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Computer-Forum
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Eternal_pain



Anmeldungsdatum: 08.08.2006
Beiträge: 1783
Wohnort: BW/KA

BeitragVerfasst am: 26.01.2013, 09:19    Titel: Atomare Variablen? Antworten mit Zitat

Ich habe das neulich zuerst in einer TV-Serie gehört und neugierig wie ich bin hab ich mal nach gegoogled:

Sehr viel hab ich darüber nicht gefunden, aber solche Variablen dienen wohl zur Thradsicherheit bei Multithreading.
Insbesondere durch das nicht ganz einfach gestaltete Multithreading in FB würde mich das Thema im groben schon sehr interessieren...

Vielleicht kann mir hier jemand in groben Zügen noch einmal genau erklären was genau Atomare Variablen sind, wo und wann finden sie Verwendung (in welcher Compilersprache werden sie primär genutzt) ect.
_________________
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 26.01.2013, 15:37    Titel: Antworten mit Zitat

Werden z.B. von C++11 geliefert (atomic).

Grob gesagt: Eine Variable ist dann atomic, wenn sie mit einem Befehl in den Speicher geschrieben werden kann. Genau dann wenn dies zutrifft, braucht man keinen Mutex mehr zum Zugriff auf die Variable (sofern dem Compiler paralleler Zugriff bekannt ist; wegen Caching).

In C++11 gibt es std::atomic, welches spezielle implementierungsabhängige Instanzen hat, die für praktisch alle Datentypen atomaren Zugriff ermöglichen.
Da das aber ohne weiteres natürlich nicht auf allen Plattformen und Prozessoren möglich ist (auf x86 ist es bspw. nicht möglich atomar einen 64-Bit Wert zu schreiben), nutzen die Templateinstanzen u.U. intern doch Locks, weswegen is ne Methode is_lock_free() gibt.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Flo
aka kleiner_hacker


Anmeldungsdatum: 23.06.2006
Beiträge: 1210

BeitragVerfasst am: 27.01.2013, 03:08    Titel: Antworten mit Zitat

Auch in C ist das moeglich, allerdings nur durch (nonstandard-)GNU-Erweiterungen.

Man muss aber dennoch aufpassen, seine Variablen volatile zu deklarieren, denn sonst kann es passieren, dass ein Thread die Aenderung niemals "sieht", weil er die ganze zeit mit dem gecacheten alten Wert weiterrechnet (warum sollte er denn auch seinen Cache loeschen, wenn man ihms nicht explizit sagt?)


Aktuelle Situation wo ich das brauche:

Ein Thread soll einen Audiotreiber mit Audiodaten versorgen, diese Daten nimmt er aus einem Datenpuffer, in dem eine Wave-Datei liegt.
Ein anderer Thread soll diese Wave-Datei bei Nutzerinteraktion manipulieren; der Audiothread muss aber immer einen *intakten* Puffer sehen, niemals einen halbveraenderten Puffer.

Das laesst sich loesen, in dem man zwei Puffer hat, und einen Pointer, der immer jeweils auf den nicht-gerade-bearbeiteten Puffer zeigt. Das "Umhaengen" dieses Pointers muss aber atomar erfolgen.

Beispiel:
aendere '0xdeadbeef' in '0xbaadf00d'
Wenn das nicht atomar laeuft, passiert folgendes:

'0xdeadbeef' wird zu '0xbaadbeef' wird zu '0xbaadf00d'

Wenn der Audiothread jetzt zu einem ungluecklichen Zeitpunkt auf den Pointer zugreifen will, wuerde er einen Segfault ausloesen, weil an '0xbaadbeef' vermutlich nichts steht.

Bei atomarem umhaengen kann das nicht passieren.
_________________
MFG
Flo

Satoru Iwata: Wer Spaß am Spielen hat, fragt nicht nach Grafik.

zum korrekten Verstaendnis meiner Beitraege ist die regelmaessige Wartung des Ironiedetektors unerlaesslich.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 27.01.2013, 11:17    Titel: Antworten mit Zitat

Ja, das deklarieren als volatile entfällt, wenn man die entsprechenden Klassen in C++ nutzt.

Was mir auch noch gerade einfällt ist, dass man nicht davon ausgehen kann, dass bestimmte Operationen atomic sind, auch wenn die Architektur bekannt ist – ich kann nicht davon ausgehen, dass auf x86 das Überschreiben eines Werts atomic ist, weil der Compiler das auf viele verschiedene Arten machen kann und es da schlicht keine Garantien gibt.

Unter Windows gibt es eine OS-API dafür: InterlockedIncrement und Konsorten, deren Laufzeitverhalten aber stark unterschiedlich ist, je nach dem, ob es der erste oder der n-te Aufrufe ist, wieviele parallele Aufrufe passieren etc.

Last but not least sollte man auch erwähnen, dass atomic Variablen langsamer sind, weil sie nicht in Registern oder Caches (sofern nicht alle vorhandenen Prozessoren auf den Cache zugreifen können, typ. z.B. L3-Cache von Dual/Quad-Core-Prozessoren) vorgehalten werden dürfen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Flo
aka kleiner_hacker


Anmeldungsdatum: 23.06.2006
Beiträge: 1210

BeitragVerfasst am: 27.01.2013, 22:16    Titel: Antworten mit Zitat

28398 hat Folgendes geschrieben:
Ja, das deklarieren als volatile entfällt, wenn man die entsprechenden Klassen in C++ nutzt.

Was mir auch noch gerade einfällt ist, dass man nicht davon ausgehen kann, dass bestimmte Operationen atomic sind, auch wenn die Architektur bekannt ist – ich kann nicht davon ausgehen, dass auf x86 das Überschreiben eines Werts atomic ist, weil der Compiler das auf viele verschiedene Arten machen kann und es da schlicht keine Garantien gibt.

Unter Windows gibt es eine OS-API dafür: InterlockedIncrement und Konsorten, deren Laufzeitverhalten aber stark unterschiedlich ist, je nach dem, ob es der erste oder der n-te Aufrufe ist, wieviele parallele Aufrufe passieren etc.

Last but not least sollte man auch erwähnen, dass atomic Variablen langsamer sind, weil sie nicht in Registern oder Caches (sofern nicht alle vorhandenen Prozessoren auf den Cache zugreifen können, typ. z.B. L3-Cache von Dual/Quad-Core-Prozessoren) vorgehalten werden dürfen.


Naja, mit GCC und Clang hat man (leider zwei unterschiedliche) Methoden, den Compiler zu zwingen, atomar mit den Variablen umzugehen; beides halt nonstandard. In Kombination mit volatile tuts das auch, und ist weitestgehend plattform- aber natürlich nicht Compilerunabhängig.
_________________
MFG
Flo

Satoru Iwata: Wer Spaß am Spielen hat, fragt nicht nach Grafik.

zum korrekten Verstaendnis meiner Beitraege ist die regelmaessige Wartung des Ironiedetektors unerlaesslich.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 28.01.2013, 17:34    Titel: Antworten mit Zitat

Sicher, dass Clang eine eigene, unterschiedliche Erweiterung hat? Eigentlich halten die sich sehr stark an den GCC (benutzen schließlich auch die gleiche C++ ABI unter Windows/Linux)…

Ansonsten ist das halt genau das von C++11 an dieser Stelle gelöste Problem; sowohl Clang 3.2 als auch GCC 4.6 können das. MSVC sollte das mit VC11 haben: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx (vergleicht die Rötung der Liste mal mit http://clang.llvm.org/cxx_status.html
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Computer-Forum Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz