🚀 go-pugleaf

Hi,

(noch ein Followup zu dem selben Artikel: Divide and Conquer :-)

Ullrich von Bassewitz (uz@wuschel.ibb.schwaben.com) wrote:
(worauf er sich bezieht, habe ich geschrieben...).
: > Da sich der ISO C++ Standard nicht ueber Shared Memory auslaesst, ist
: > ALLES unportable. ... und ich lege Dir trotzdem problemlos bestimmte
: > Objekte in Shared Memory an (placement-new laesst gruessen).  Ausserdem

: Tja, reingefallen (aber troeste Dich, so ging's mir auch :-).

Ich wuesste nicht wo ich reingefallen bin, aber das haengt vermutlich
damit zusammen, das ich die Nebenbedingungen, die ich an die Objekte
stelle, um sie in Shared Memory anzulegen, nicht genannt habe (note:
"bestimmte Objekte"). Da ich schonmal mit Shared Memory zu tun hatte,
bevor ich das erste Mal versucht habe, C++ Objekte in Shared Memory zu
packen, bin ich da nicht mehr reingefallen.

: Natuerlich laesst sich ein Objekt mittels placement new in das Shared Memory
: legen. Aber rate mal, was passiert, wenn Du von einem anderen Programm (das
: natuerlich auch Zugriff auf das SM haben muss) virtuelle Methoden aufrufst?
: Stichwort VMT (oder vtable) Zeiger...

Ja, sicher: Virtuelle Funktionen duerfen die "bestimmten Objekte" nicht
enthalten.  Hier ist die Liste der Einschraenkungen fuer eine Klasse,
deren Objekte in Shared Memory angelegt werden sollen:

- keine virtuellen Funktionen
- keine virtualle Vererbung. Mehrfachvererbung wuerde ich auch
  vermeiden, u.U. kann man Mehrfachvererbung auch nicht benutzen: Dazu
  habe ich mir noch keine Gedanken gemacht... (ich wuerde vermutlich
  sogar, wenn moeglich, ganz auf Vererbung verzichten: virtuelle
  Funktionen gehen sowieso nicht...)
- keine Referenzen als non-static members
- keine Pointer als non-static members

Zumindest unter UNIX gibt es keine Zusicherung, dass die Adressen in
allen Programmen, die sich das Shared Memory Segment teilen, identisch
sind. Daher die drei zusaetzlichen Einschraenkungen (ich kann mir
vorstellen, dass andere Platformen diese Einschraenkungen nicht
haben...). Es gibt aber mit den Objekten nochmehr Probleme:

- auf Array-Objekte sollte verzichtet werden (also kein 'new(...)
  foo[..]'): die Anfangsadresse laesst sich in den anderen Programmen
  nicht portable ermitteln.
- ggf. (wenn externe Resourcen verwaltet werden) muss dafuer gesorgt
  werden, dass ein passender Destruktor (und auch nur EINER) aufgerufen
  wird.
- alle Programme sollten mit dem selben C++ Compiler compiliert sein
  (sonst sind nachher die Member in unterschiedlicher Reihenfolge
  abgelegt: Man kann naemlich nicht nur POD in Shared Memory ablegen).
- alle Programme sollten exakt die selbe Klassendeklaration verwenden
  (nicht etwa 'public' und 'private' Specifier verschieben).

Abgesehen davon, dass modifizierende Zugriffe zwischen den Programmen
synchronisiert werden muessen, fallen mir jetzt gerade keine
Einschraenkungen mehr ein. Dafuer sind das die selben Einschraenkungen,
wie wenn man ein (platform-spezifisches) File mit 'mmap(2)' in den
Speicher "mapped" und da drin Objekte angelegt (zum Beispiel um eine
einfache Persitance zu basteln). Aber hier geht's um C++, nicht um UNIX
low-level Programmierung...
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic