OPropertySetHelper, one of the central base classes for implementing
X(Multi/Fast)PropertySet, applies the following logic when one or more
values are to be set
- convertFastPropertyValue is called, giving the implementation the
chance to normalize the to-be-set property value
- possible veto listeners are called to veto the property change
- setFastPropertyValue_NoBroadcast is called, giving the implementation
the chance to actually set the new value
- possible change listeners are called to be notified of the property
The first and the third step are invoked with the classes mutex
locked, the second and the forth without a mutex lock - which is fine
Unfortunately, this implies that if the implementation of
setFastPropertyValue_NoBroadcast needs to set another (dependent)
property value, it is somewhat lost: Invoking
setFastPropertyValue_NoBroadcast for this other property would miss
the notifications, and invoking setPropertyValue would (implicitly) do
all the notifications with a locked mutex, which sooner or later will
lead to a deadlock.
So, setDependentFastPropertyValue has been introduced at the
OPropertySetHelper. It is intended to be called from within
setFastPropertyValue_NoBroadcast, and it will carry out the first and
the third step from above, actually converting and setting the new
property value, but it will save the property change notification for
the point in time where the first setFastPropertyValue_NoBroadcast
returns, and thus the own mutex can be released.
Multiple calls to setDependentFastPropertyValue can be made, the
resulting change notifications are collected.
Note that it is not feasible to use this for constrained properties -
this would required notifying veto listeners from within
setDependentFastPropertyValue, which is deadlock-prone, again, since
the method by definition needs to be called with the mutex locked.