Table of Contents
This chapter describes the pointer model that is used in the Massiv.
One of the basic design goals is to allow the Core to delete local object instances without notifying an user. This is needed for implementation of transparent object migrations, when object instance on the local node is deleted, transmitted over the network and created again on the other node, object replication, etc. Because of this it is obvious that the application can not use native pointers (or references) to reference managed objects. The Core must know all the references the application has made for various reasons (garbage collection, implicit migration groups definition). There must be a way to detect what objects are active (their code is running or data being used).. References must be durable and must be able to identify all objects reliably, including remote objects and objects that migrated out of the local node. There should not be any major differences between a local pointer (that references an object that just happens to be present on the local node) and a remote pointer in terms of declaration and basic use. The Core should prevent client from dereferencing invalid pointers.
The Core solves these problems by defining Massiv::Core::ObjectPointer, which is a replacement for native pointers. It is a sort of "smart pointer" that satisfies all the discussed properties. Using object pointers is nearly the only legal way how the application can reference managed objects, even local objects must be referenced by them. When we are talking about managed pointers, object pointers are ment. .
![]() | Note |
---|---|
It is obvious that at some point managed pointers must be converted to native C++ pointers in order to access object members or invoke their methods. However this is done internally by a pointer logic. Accessed objects are active-pinned (activated) before the access and unpinned when the native reference is released (if you are interested in the trick that achieves this consult the Massiv Core Programmer's Documentation). The Core refuses to delete pinned objects (such a request will be automatically delayed until the object is unpinned). This allows application to access object members through the C++ this. |