組み込みコミュのデッドロックを発生させない設計の方法を教えてください。

私は、デッドロックを発生させない設計を考えたが、これが正しいかどうか、または、別の方法があるかを検討してください。

さて、デッドロックの発生のメカニズムとは、たいていの本には次の様な事が書いてある。
資源Aと資源Bがありました。
１つのタスクは、資源Aを排他制御でロックした後、資源Bを排他制御でロックして、その後、資源AとBとにかかった排他制御を解放しました。
もう一つのタスクは、資源Bを排他制御でロックした後、資源Aを排他制御でロックし、その後、資源AとBとにかかった排他制御を解放しました。
この時、資源AとBは、とある事象によってロックがかかる事象が発生します。
それをデッドロックと申します。
ざっと、こんな具合の話があるものだ。
私は疑問に思った、資源Aを使うためにロックしたのならば使った後に資源Aをアンロックすれば良い。そして、次に資源Bを使う時も資源Bのためにロックしたのならば使った後に資源Bをアンロックすれば良い。
これで、デッドロックは避けられると考えた。
しかし、事態はそうじゃなかったらしい。
２つの排他制御をするためにロックして使わなければならない資源があるとしたら、順番がA→Bならば、他の順番もA→Bでなければデッドロックを回避できない。もし、逆の事があるとしたらデッドロックが発生する。
こう述べたいのだろう。

　では、こういうオブジェクト指向型のジョブの設計のパターンがあるとする。
タスク間通信用のデーターベースには必ず排他制御があるものとして、DBとして表現する。
タスク１→DB＿X→タスク２→DB２→タスク３→DB＿Y→タスク４
タスク５→DB＿Y→タスク６→DB２→タスク７→DB＿X→タスク８
この時は、DB_XとDB_Yは、デッドロックする可能性が高いです。
特にジョブの中のタスクが隙間無く流れていれば、デッドロックになる可能性が高い。
もし、デッドロックをなくすとすれば、
タスク５→DB＿X→タスク６→DB２→タスク７→DB＿X→タスク８
というように、排他制御のある部分の順番を整理しなおして設計し直さなければならなくなってくる。