QObjectComputedProperty offers a value to the bindable property dependency tracking system without having its own storage for that value.
When using QObjectComputedProperty, it is the programmers responsibility to call the markDirty() method whenever the value might have changed. However, calling markDirty() triggers markDirty() of all downstream properties in the dependency graph. In addition, if there are any eager evaluating properties downstream, it might trigger re-evaluation of those. This in turn will trigger a read of the QObjectComputedProperty we are just setting to dirty. Thus we have to guarantee that it can be read the moment we call markDirty().

This occured to us when porting QThreadPool:
https://codereview.qt-project.org/c/qt/qtbase/+/326626/9

Quote from our discussion there:

There are many places where activeThreadCountData.markDirty() is being
called while the mutex is held. markDirty() will set all downstream
properties dirty. If any of the downstream properties is eagerly evaluating
(because someone subscribed on it or because it has a signal), the
downstream property will read activeThreadCount.
The activeThreadCountComputed() method tries to lock the mutex,
so this will lead to a deadlock.