Medical Imaging Interaction Toolkit
2016.11.0
Medical Imaging Interaction Toolkit
|
The DataStorageAccessRule inherits from the ISchedulingRule class. DataStorageAccessRule are used to restrict the adding and removing of DataStorage nodes in multi-threaded scenarios. Only DataStorageNodes within different branches can be modified concurrently. The idea and its restrictions is explained in the sections and diagrams below. More...
#include <mitkDataStorageAccessRule.h>
Public Types | |
enum | RuleType { ADD_RULE, REMOVE_RULE } |
Public Types inherited from berry::Object | |
typedef Object | Self |
typedef berry::SmartPointer< Self > | Pointer |
typedef berry::SmartPointer< const Self > | ConstPointer |
typedef berry::WeakPointer< Self > | WeakPtr |
typedef berry::WeakPointer< const Self > | ConstWeakPtr |
Public Member Functions | |
berryObjectMacro (DataStorageAccessRule) | |
DataStorageAccessRule (mitk::DataStorage::Pointer myDataStorage, mitk::DataNode::Pointer myDataNode, DataStorageAccessRule::RuleType myRule) | |
bool | Contains (berry::ISchedulingRule::Pointer otherISchedulingRule) const override |
bool | IsConflicting (berry::ISchedulingRule::Pointer otherISchedulingRule) const override |
Public Member Functions inherited from berry::Object | |
virtual QString | GetClassName () const |
virtual Reflection::TypeInfo | GetTypeInfo () const |
virtual QList< Reflection::TypeInfo > | GetSuperclasses () const |
virtual void | Delete () |
QDebug | Print (QDebug os, Indent Indent=0) const |
virtual QString | ToString () const |
virtual uint | HashCode () const |
virtual bool | operator< (const Object *) const |
void | Register () const |
void | UnRegister (bool del=true) const |
int | GetReferenceCount () const |
void | SetReferenceCount (int) |
void | AddDestroyListener (const MessageAbstractDelegate<> &delegate) const |
void | RemoveDestroyListener (const MessageAbstractDelegate<> &delegate) const |
virtual bool | operator== (const Object *) const |
Public Attributes | |
RuleType | m_Rule |
Additional Inherited Members | |
Static Public Member Functions inherited from berry::Object | |
static const char * | GetStaticClassName () |
static Reflection::TypeInfo | GetStaticTypeInfo () |
static QList< Reflection::TypeInfo > | GetStaticSuperclasses () |
Protected Member Functions inherited from berry::Object | |
Object () | |
virtual | ~Object () |
virtual QDebug | PrintSelf (QDebug os, Indent indent) const |
virtual QDebug | PrintHeader (QDebug os, Indent indent) const |
virtual QDebug | PrintTrailer (QDebug os, Indent indent) const |
Protected Attributes inherited from berry::Object | |
QAtomicInt | m_ReferenceCount |
QMutex | m_ReferenceCountLock |
The DataStorageAccessRule inherits from the ISchedulingRule class. DataStorageAccessRule are used to restrict the adding and removing of DataStorage nodes in multi-threaded scenarios. Only DataStorageNodes within different branches can be modified concurrently. The idea and its restrictions is explained in the sections and diagrams below.
returns true or false depending if conflictions with another rule are found
two add rules are always allowed since there are no conflictions when adding nodes concurrently. The final order the nodes are finally added has to be checked by the programmer of the particular job
<a name"RemoveRules">
two jobs holding remove rules can be executed concurrently since all removing scenarios do not cause conflictions. If two jobs are trying to remove the same DataTree node the job by itself needs to check if the node is still available before executing the removing command
<a name"RemoveAddRules">
adding and removing of DataTree nodes concurrently can cause serious errors and needs to be restricted. Performing add and remove operations on different DataStorage branches can be done concurrently since no conflictions are expected. the performing of add and remove operation on the same DataNode, its parent nodes or child nodes of the same branch by different jobs is not allowed. Jobs holding rules that are trying to perform such operations are blocked until the running job is done.
only necessary for a specific type of scheduling rules. Has to be used if IScheduling rules are composed into hierarchies. In such scenarios the contains(...) method specifies the hierarchical relationships among the locks. For example if a method tries to acquire a specific * rule to lock a specific directory it needs to check if no job is holding a rule for one or more subdirectories. For all cases in which no composing of IScheduling rules is needed the Contains(...) method only needs to check if two jobs are holding exactly the same IScheduling rule on the same object. Normally this can be achieved by just calling the IsConflicting(...) method.
Definition at line 85 of file mitkDataStorageAccessRule.h.
Enumerator | |
---|---|
ADD_RULE | |
REMOVE_RULE |
Definition at line 90 of file mitkDataStorageAccessRule.h.
mitk::DataStorageAccessRule::DataStorageAccessRule | ( | mitk::DataStorage::Pointer | myDataStorage, |
mitk::DataNode::Pointer | myDataNode, | ||
DataStorageAccessRule::RuleType | myRule | ||
) |
mitk::DataStorageAccessRule::berryObjectMacro | ( | DataStorageAccessRule | ) |
|
override |
|
override |
RuleType mitk::DataStorageAccessRule::m_Rule |
Definition at line 92 of file mitkDataStorageAccessRule.h.