R
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.
