Objekte in Shared Memory (Q: gcc 2.7.1: Aufruf einer Konstruktormethode aus einer anderen)

Thread View: de.comp.lang.c++

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Dietmar Kuehl Thu, 29 Feb 1996 00:25

#1709

Author: Dietmar Kuehl
Date: Thu, 29 Feb 1996 00:25

66 lines
3882 bytes

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

Re: Objekte in Shared Memory (Q: gcc 2.7.1: Aufruf einer Konstruktormethode aus einer anderen)

#1712

Author: Ullrich von Bassewitz
Date: Thu, 29 Feb 1996 07:43

32 lines
1912 bytes

Dietmar Kuehl (kuehl@uzwil.informatik.uni-konstanz.de) wrote:
> 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.

Da haben wir uns dann wohl missverstanden. Mir ging's darum, Objekte einer
bestehenden Klasse (u.a. Strings, wenn Du's genau wissen willst) in das SM
zu legen. Und das geht im Normalfall nicht, weil diese eben virtuelle
Funktionen haben. Natuerlich kann ich spezielle Objekte konstruieren, bei
denen das klappt, und natuerlich kann ich ein Verwaltungsobjekt schreiben,
dass Speicher im SM kappselt.

Fuer eine echte Applikation, die auch jemand bezahlen muss versuche ich aber
bereits bestehenden Code weiterzuverwenden, und das beste waere natuerlich
gewesen, wenn ich Strings (oder was auch immer, Library-Klassen eben) in das
SM legen koennte. Das geht aber im Regelfall nicht.

Fuer "bestimmte" Objekte (das Wort habe ich uebersehen, ich gebe es zu) ist
das was Du sagst also voellig richtig. In der Praxis hat es aber keine
Bedeutung.

Gruss

        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads