francois-normandin
commented
6 years ago 
Starting with version 1.3.0, SMO will be able to be declared as a shared resource from the Create method.
Behavior of this new feature:
- Only the shared resource attribute is set by this method. No ownership relation is created, since there is no caller that can encapsulate the ownership attributes. (Ownership is managed by framework through a Shared Key that the dependency stores in its memory, and which only the owner is able to recompute through a public GUID and a secret key)
- Once a SMO subsystem declares a static dependency (onStart) or launches a dynamic dependency using the LaunchDependency public method, it will request ownership of the shared resource. If it is already owned, it will not manage its lifetime. If it is not already owned, it takes ownership and manages its lifetime. The Stop/Destroy commands would not work anymore, unless provided with the correct shared key.
using the Launch Dependency:
using Statically-defined Dependencies:
It is easy to prevent ownership transfer (build sharedKey using self-GUID + secretKey of Self), but unfortunately it leaves the issue of stopping and destroying the subsystem (managing its lifetime). How can we ensure that the right owner (the caller VI) is the only entity able to manage the lifetime or to delegate it? It requires adding an extra gizmo which cannot be handled automatically by the framework. IMO, it creates confusion and requires inside framework knowledge to use a simple feature.
Currently, there is no mean to declare a subsystem as shared dependency without having an owner which manages the lifetime of the shared instance. Feature request is to allow a subsystem to self-declare itself as a shared dependency, by defining itself as owner. (Filtering should be done at start/stop methods to prevent recursive calls or doubling of instances.)