問題3-46〜49

この部分では、mutexが登場し、make-sirializerの実装が紹介されています。さらに、デッドロックについても言及されています。
問題3-46。mutexが保持しているフラグを調べ、利用可能ならばフラグを上げる手続きであるtest-and-set!ですが、この中には、｢フラグを調べる -> 利用可能ならフラグを上げる｣という流れがあります。ここを直列化しないと、今まで見てきた事例のように、あるプロセスがフラグを調べ、そのフラグを上げる前に、別のプロセスがフラグを調べ、利用可能だと判断してしまうという現象が発生してしまいます。
問題3-47。セマフォを実装せよという問題ですが、mutexをリスト化すれば良いのでは程度の発想しかできませんでした。
問題3-48。デッドロックに関する問題で、この問題に書かれているような回避法が上手くいく理由を考えてみます。残額交換手続きを実行する際、関連する二つの口座を直列化する訳ですが、Peterがa1->a2、Paulがa2->a1の順で口座を直列化すると、Peterがa1を直列化し、Paulがa2が直列化した後、Peterはa2の獲得を試み、Paulはa1の獲得を試みる時に、それができず、お互いに何もできなくなってしまいます。そのため、serialized-exchange手続きの中で、口座を直列化する順序を考えてやる必要があります。この手続きに渡される口座オブジェクトを、渡された順に直列化するという既存のロジックを改め、渡された口座オブジェクトの口座番号を調べ、番号の低い方から直列化するように変更すれば、Peter/Paul共に、同じ順序で口座オブジェクトを直列化しようと試みるので、a1がダメならa1が解放するまで待つという正しい流れが生まれます。
問題3-49。上記のような回避法が上手くいかないシナリオとして、例えば、ある口座オブジェクト自体に振込先口座と振込額の対データあったとして、その振込先を知るためには、そのデータを保持している口座オブジェクトにアクセスしなければならない場合、前もって交換する二つの口座を口座番号によって順序良く直列化することができなくなります。
この｢3.4 並列性：時が本質的｣の節に取り組みながら、自分の知識不足を痛感しました。また、こういう並列性の諸問題については、モダンオペレーティングシステムという本に詳しく解説されていたことを思い出し、改めて勉強し直す必要がありそうだと思いました。