まあ、>>510の最終目標の1つは、シーングラフを構築する上でタスクを使って並列処理を行うって意味なんでしょ。
タスク単位で他タスクの保有するオブジェクトの参照や依存関係を明確にして、
並列処理できる分については、自動でスレッドにタスクを投げ込んでやろうとしてるのかな。

参照構造はその第1歩って事なんだと思う。DBって言葉使うと紛らわしいよね。一般的なDBMとは単語の意味合いがちょっと違うかな。
タスクからのオブジェクトの所有/解放と他オブジェクト参照の可否を組込む辺りから先ずは始めるのがいいと思う。
でも、並列タスクが相互干渉する状態での同期処理となると頭抱えちゃうかな。
最後にこのようなタスクが残るとクリティカルパスに影響するだろうから、
同期/非同期なのかは、個別に指示する必要がありそうな感ではある。全部動的にするのは難しいね。

タスクの粒度を細かくすると、参照構造がばらけて、並列化しやすくなるだろうけど、タスクプールが肥大になってかえってオーバヘッド生みそうだし、、
逆に粒度を荒くすると、並列化が困難になりそうだよね。その辺のバランス調整も難しそうだ。

他にもアイディアとしては、前フレームでの1タスクの実行時間を保持しておき、
それを次フレームでのタスク予想時間として利用して、効率的に分配するとかかな。

俺はタスクは使わない派だが、>>510は応援するよ。ネタとしては楽しいと思う。
始めソースを見ても目的が意味不明だったが、言ってることは分かった。
>>2とは、目標としているところは全然違うっしょ。
あと、参照構造についての意見はまたそのうちまとめて書くよ。