Fortran shared pointers

A shared pointer is a concept that is useful in a situation where there can be multiple references to a particular object, the object must continue to exist while any references to it are extant and the object must cease to exist when no references to it are extant. A shared pointer in this situation acts as the reference, with coordination between shared pointers that reference the same object to manage the lifetime of the object.

A zip archive of source code that shows how a generic shared pointer can be implemented in a source library in Fortran 2008 is available under an Apache 2.0 licence, and can be found at www.megms.com.au/download/shared-pointers.zip (revision 2223 from 2016-06-23). This particular implementation uses reference counting. The generic nature is achieved by using INCLUDE to bring source into the scope of a module that expects the referenced object to be of a type named object_type.

Two variants are provided, one that permits weak references to the referenced object, and one that does not. Weak references do not prolong the life of the referenced object, but can be used to test the existence of the referenced object. They can be used to break reference cycles that result in objects existing indefinitely, even in the case that there are no references to objects in the cycle outside of the objects themselves. There is a small amount of overhead associated with the support for weak references.

The shared pointer functionality is encapsulated in a type named SharedPointer, while the weak reference functionality is in a type named WeakPointer. Note that SharedPointer and WeakPointer objects are not (typically) Fortran pointers (i.e. objects with the POINTER attribute) - instead they are wrappers around a Fortran pointer. Fortran pointers and Fortran pointer components are used to access the referenced object from a SharedPointer object.

Both provided variants internally reference the object using a Fortran pointer that is a polymorphic scalar. Other variants are possible and likely useful - using a non-polymorphic pointer, using a pointer to an object with some specified rank, but a polymorphic scalar is a reasonably general case.

The filename of the source to include for the variant that does not support weak pointers is PolyScalarSharedPointer.i90, while the filename for the variant that does support weak pointers is PolyScalarWeakSharedPointer.i90. The example programs for each variant are named similarly.

The means by which the source code for the SharedPointer type is used means that there can only be one SharedPointer type (and WeakPointer too, where applicable) defined in a particular module. This also means that each definition of a SharedPointer type is a distinct type. In the event that it is needed to have more than one SharedPointer types accessible in the same scope, then use renaming must be used to rename all the types to unique names.

Operations that mix different SharedPointer types will not be permitted by the compiler. This includes operations that might otherwise make sense given the type hierarchy of the referenced types - i.e. you cannot assign a SharedPointer object that references an extension type to a SharedPointer object that expects to reference a parent type, even though such a pointer assignment operation is permitted using Fortran pointers.

A brief example of how the source code is used:

MODULE SharedPointerModule
  ! The included code requires that the type being referenced be 
  ! known in the current scope by the name `object_type`.  If the 
  ! type is defined in another module, use renaming can be used 
  ! to achieve this.
  USE SomeOtherModule, object_type => type_for_referenced_object
  IMPLICIT NONE     ! If desired.
  PRIVATE           ! If desired.
  
  ! These are the identifiers defined by the included source 
  ! below.  Because the default accessibility of this module is 
  ! PRIVATE, if it is desired that scopes that USE this module have 
  ! access to these identifiers then they need to be explicitly 
  ! specified to be PUBLIC.
  PUBLIC :: SharedPointer, Acquire, Get
  
  ! The include line must come at the end of the specification part 
  ! of the module, before any module subprograms  The included
  ! source has the CONTAINS statement that separates the specifcation 
  ! part and module subprogram part of the module.
  INCLUDE 'PolyScalarSharedPointer.i90'
  
  ! Other module subprograms could go here.
  SUBROUTINE example
    ! A shared pointer for referencing objects of type object_type.
    TYPE(SharedPointer) :: sp
    ! A temporary Fortran pointer used to supply the object to the 
    ! shared pointer.
    CLASS(object_type), POINTER :: tmp
    
    ! Allocate the Fortran pointer.
    ALLOCATE(tmp)
    
    ! Place control of the lifetime of the object with a shared pointer.
    sp = SharedPointer(tmp)
    
    ! The object that was originally referenced by `tmp` will exist 
    ! until all there are no more SharedPointer objects referencing 
    ! the object.  
    !
    ! In the meantime the referenced object can be accessed using the 
    ! `Item` component of a shared pointer object, or via the Get 
    ! generic function that has a Fortran pointer result.
    sp%Item = ...
    Get(sp) = ...
    
    ! Other shared pointers referencing the same object can be created 
    ! using intrinsic assignment.
    BLOCK
      TYPE(SharedPointer) :: sp_other
      sp_other = sp
      ! You can explicitly set a shared pointer to not reference 
      ! any object by using the structure constructor with 
      ! no component specifiers.
      sp_other = SharedPointer()
    END BLOCK
    
    ! In this case the shared pointer `sp` is finalized at the 
    ! end of this procedure because it is an unsaved local variable.  
    ! When it is finalized it will cease to reference an object.  In 
    ! this example there are no other shared pointers referencing that 
    ! object so the object that was originally associated with the 
    ! `tmp` Fortran pointer will be automatically deallocated.
  END SUBROUTINE example
END MODULE SharedPointerModule

An alternative to using the SharedPointer generic function to construct a SharedPointer object is to use the Acquire generic subroutine.

The IsAssociated generic function can be used to test whether a SharedPointer or a WeakPointer object currently references an extant object.

If the shared pointer references an object, the Get generic function will return a Fortran pointer to the object. The Fortran 2008 feature that permits a function-reference with a data pointer result to designate a variable then permits a reference to this function to appear on the left hand side of an assignment expression, or it can be used in an expression.

It is possible to break the SharedPointer encapsulation using certain language features - see the "evil" internal procedures in the example main programs for elaboration:

• Using the SOURCE= specifier of an ALLOCATE statement to copy the value of a SharedPointer object (either when that SharedPointer object is the immediate subject of the allocation, or it is a subobject of the allocation) results in creation of a new SharedPointer object that references the same referenced object (if any), without the internally managed reference count being updated. This will lead to non-conforming execution, where the internal control block will be deallocated before the last SharedPointer referencing that control block has been finalized.
• If a SharedPointer object that references an object is passed as an actual argument to a procedure where the dummy argument has the VALUE attribute, and then the dummy argument is redefined in the procedure by intrinsic assignment, then the finalization invoked as part of the intrinsic assignment will decrease the reference count for the object without there having been a corresponding increase for the reference count when the procedure was invoked. If the object referenced by the dummy argument changes as a result of the assignment, then this will lead to non-conforming execution, where the internal control block for the original object will be deallocated before the last SharedPointer referencing that control block has been finalized, and will result in a memory leak, as the dummy argument, now referencing a different object, is not finalized when the procedure terminates.

Building from source

The source code should be compilable by a Fortran 2008 compiler.

Intel Visual Fortran 17.0 beta was the compiler used for development. With that compiler, the /standard-semantics switch (or its equivalent on non-Windows platforms) is required to compile the example programs.

Note that gfortran current trunk (at the time of writing version 7.0.0 20160615 (experimental)) cannot be used to compile the example programs (and likely any program that includes the source) due to PR71580.

Feedback

Questions, queries and quibbles can be sent to ff08@megms.com.au.