C++ Zugriff auf externen Speicherbereich

danke roker002 für den link. aber leider ist da auch nur das allgemeine konzept zur anwendung von volatile beschrieben. das konnte/habe ich auch so in verschiedener literatur inkl. Stroustrup nachgelesen und verstanden. das allgemeine konzept erklärt jedoch nicht wie ein anderer prozess/treiber/hardware genau diese variable schreibt bzw. wie ich auf den speicherbereich außerhalb meines eigenen prozesses zugreife. Im übrigen beabsichtige ich nicht auf diesen bereich schreibend zuzugreifen (s.o. definition jeweils mit const abgesichert). mir ging es in dem konkreten beispiel darum den aktuellen wert der rtc auszulesen. leider wird unter windows stets die exception ausgelöst, was weiter nicht tragisch ist, da ich als alternative die performance counter nehmen kann um das gleiche zu erreichen, was ich über die rtc hätte machen wollen. mir sah es nur etwas "performanter" aus, direkt auf einen speicherbereich zuzugreifen ohne die windows api zu verwenden. schließlich wäre das einsatzgebiet, wie oben bereits erwähnt, in einem kritischen bereich des programms, sprich es wird sehr oft durchlaufen und sollte deswegen sehr performant sein. das volatile sehe ich zum jetzigen zeitpunkt nur noch als eine möglichkeit um dem kompiler zu sagen: "Hey, wenn das programm die variable verwendet, dann nimm immer den tatsächlichen wert aus diesem speicherbereich und lass die finger von irgendwelchen optimierungen!". ich könnte es dann für threads verwenden wo sichergestellt ist, das der eine thread nur lesend drauf zugreift, während ein 2. thread nur schreibend drauf zugreift. aber das ist dann auch nur für threads innerhalb eines prozesses möglich, prozessübergreifend wirds dann nicht möglich sein, weil eben der zugriff durch windows geblockt wird. ich bin mir auch dessen bewusst, das ich mit hilfe von mutex / semaphore eine synchronisierung implementieren muss um race conditions zu vermeiden. Nichts desto trotz, vielen dank für deine anteilnahme...
grüße rossibaer
 
wie du dieses speicherbereich nutzen kannst ist einfach. da er immer fest vorgeschrieben ist kannst du in jedem programm die diese var benutzen will statisch zu speichern. naja dies wäre eine sehr schlechte lösung, da der speicherbereich inzwischen auch von den anderen programmen benutzt werden kann. Du wirst im wahrscheinlichsten fall memory violation fault bekommen. wenn du also win benutzst dann schreibe den speicherwert in die registry. natürlich ist es auch keine optimale lösung. eine andere wäre den wert in eine datei zu schreiben. du musst halt nur wissen, wie angreifssicher ist dein Programm. willst du es nur für eigene zwecke benutzen oder baust du ein programm für eine firma. das sind die fragen. für die eigene zwecke, würde ich einfach den wert in eine datei speichern. wenn du für jemanden eine software baust dann würde ich den wert verschlüsseln. Immerhin gehört dieser speicherbereich zu deine kritische stelle.
 
Rossibaer schrieb:
...Es geht mir um die Technik "Memory mapped I/O"...

ich glaube kaum, dass sich in einem Ring3-Prozess überhaut irgendwelche hardware-mapping‘s befinden. Wenn die zur Addr. 0x1234 gehörige Page Belegt ist, dann sicher nicht mit einem mapping (z.B. ports,bios,register,...).

Grüße Woey

PS: Ich lass mich gerne eines Besseren belehren
 
@roker002: für die inter-process Kommunikation, bieten sich soviele Möglichkeiten an: Dateien, Registry, Datenbank, Windows-Messages, COM, DDE etc. Da sehe ich keine Probleme. Habe das alles schonmal angewendet... :) Also an Möglichkeiten mangelt es nicht, mir sind auch die damit verbundenen Probleme/Risiken sehr bekannt. Ich wollte lediglich das Beispiel aus dem Buch zum Laufen bringen und so meinen Wissenshorizont erweitern. Schade das es nicht so geht, wie gedacht... Zu meinem Programm, ja, ich mache es erstmal privat für mich und werde es sicher später, wenn ich es nicht schon vorher abbreche, in die Weiten des Internets releasen.

@Woey: Sorry, leider zu spät, das Thema ist durch... Danke trotzdem für deinen Beitrag. PS: Belehren muss ja nicht sein, es reicht schon eine andere Ansicht zu vermitteln... ;)
 
Zurück
Oben