Threading Teil der Sprache?
-
großbuchstaben schrieb:
rapso schrieb:
jetzt hast du also atomics benutzt und bist total sicher, stimmts? nein, das ist falsch wenn du das allgemein annimmst. bei x64 binaries als beispiel aendert die CPU die schreibreihenfolge von unabhaengigen speicheraddressen.
wenn ein anderer Thread meinen Schreibvorgang stören kann, nachdem ich ihn "angemeldet" habe und bevor ich ihn als erledigt "abgemeldet" habe, ist mein Schreibvorgang aus meiner Sicht nicht mehr atomar. Ich habe ausdrücklich atomar auf die verschiedenen Ebenen bezogen, von Library-Funktionen bis auf CPU-Ebene.
die von dir angemeldeten schreibvorgaenge waren atomar. damit war dein zugriff der zwischendurch passiert und nicht atomar war trotzdem nicht sicher. der zugriff war nur ein beispiel, es kann jede andere blackbox sein die du nicht komplett mit atomics ausschmueckst. Aus sicht der hardware waren nur die atomics volatile in dem fall.
oder suggerierst du gerade, dass du alle memory operationen atomar machen wuerdest um sicher zu gehen?
-
Kellerautomat schrieb:
rapso schrieb:
atomare befehle braucht man nicht fuers lesen
Doch, braucht man. Wer so eine Schleife schreibt, ist selbst schuld.
du spassmacher
-
rapso schrieb:
die von dir angemeldeten schreibvorgaenge waren atomar. damit war dein zugriff der zwischendurch passiert und nicht atomar war trotzdem nicht sicher. der zugriff war nur ein beispiel, es kann jede andere blackbox sein die du nicht komplett mit atomics ausschmueckst. [...]
oder suggerierst du gerade, dass du alle memory operationen atomar machen wuerdest um sicher zu gehen?dein Einwand mit dem write reordering trotz Atomarität auf Anweisungsebene ist berechtigt. Ich habe aber trotzdem den Eindruck, wir meinen ungefähr das Gleiche.
-
großbuchstaben schrieb:
rapso schrieb:
die von dir angemeldeten schreibvorgaenge waren atomar. damit war dein zugriff der zwischendurch passiert und nicht atomar war trotzdem nicht sicher. der zugriff war nur ein beispiel, es kann jede andere blackbox sein die du nicht komplett mit atomics ausschmueckst. [...]
oder suggerierst du gerade, dass du alle memory operationen atomar machen wuerdest um sicher zu gehen?dein Einwand mit dem write reordering trotz Atomarität auf Anweisungsebene ist berechtigt. Ich habe aber trotzdem den Eindruck, wir meinen ungefähr das Gleiche.
ich bin dagegen, du bist dafuer
sorry, nicht dass ich dagegen motzen will, aber ich halte atomare operationen an sich wirklich nicht fuer die loesung noch fuer das was man erreichen moechte. was wichtig ist, ist wann welchem thread auf welche weise daten gehoeren.
Wenn du z.b. sicher stellst dass es immer nur einen schreibenden und einen lesenden (bzw monitoring) thread gibt fuer pro variabel mit der kommuniziert wird, kommst du ohne atomics im ganzen program aus.
Als beispiel ein compressions tool:
du kannst eine pipeline architektur aufbauen, dass ein thread blockweise daten einliest, ein thread macht dictionary encoding auf dem packet, ein thread macht entrophy encoding und ein thread verschickt die daten.du kannst die blocks in einem ringbuffer halten, zum daten-ringbuffer kannst du dir einen status-ringbuffer anlegen in dem immer die stage vom packet steht. es ist sichergestellt, dass nur die stage darauf schreibt die im status-flag fuer das packet steht. die stage erhoeht das status-flag und nur die nachfolgende kuemmert sich um das packet, egal wieviele auf das flag pollen.
es wird in dem ganzen system, trotz threading, nie eine atomare operation benoetigt, weil es keine races zwischen den threads geben kann.
die ursprungsfrage darauf bezogen ist, braucht man einen speziellen support in der sprache, oder koennte man mit einer externen lib das in jeder sprache realisieren?
Ich denke es geht nicht grundsaetzlich nur mit einer externen lib, da die sprache z.B. annehmen koennte, dass es kein 'aliasing' gibt zwischen den daten-ringbuffer und dem status-ringbuffer, und selbst wenn eine externe lib eine atomicadd-funktion anbieten wuerde um den status flag zu aendern, koennte die sprache ein instruction reordering vornehmen mit dem das status-flag beschrieben wird bevor das packet rausgeschrieben wird, weil es im context von nur einem thread legitim ist, solange dabei die dependencies innerhalb des einen thread-flows beachtet werden.weiter gebe es die frage, ob die sprache ueberhaupt eine moeglichkeit bietet atomics anzubieten.
In Lua z.B. werden daten ueber ein stack objekt mit c++ ausgetauscht. wuerdest du mit demselben lua-context aus zwei verschiedenen threads funktionen aufrufen in der hoffnung dass sie dann zusammenarbeiten koennen, haettest du trotzdem keine einfache moeglichkeit eine atomic operation als 'lib' anzubieten. du muestest ein custom objekt mittels 'userdata ptr' anbieten, damit muestest du auch fuer jeglichen zugriff eine funktion anbieten.
aber das wuerde weiterhin nicht garantieren dass obriges pipeline system funktioniert, eben wegem dem moeglichen reordering und lua-internem caching.
dir wuerde als nichts anderes uebrig bleiben, als alles, was zwischen zwei threads ausgetauscht werden soll in deine userdata zu stecken.
es wuerde also mit einer architektur enden, die multi-processing entspricht und nicht mehr multi-threading, da daten nicht mehr geteilt wuerden, sondern mittels funktionen zwischen den eigenstaendig lebenden prozessesn (auser nutzer sicht) relokalisiert werden.