DragonFly BSD(ドラゴンフライ ビーエスディー)は、NetBSDやFreeBSDと同じくBSDの子孫の1つの、UNIXライクなオープンソースのオペレーティングシステムである。がプロジェクトリーダーとなり、2003年にFreeBSD 4.8-STABLEから分岐する形で開発が始まり、2004年7月12日に初のメジャーバージョンであるDragonFly BSD 1.0が公開された。DragonFly BSDは、FreeBSD 4.xの後継というだけでなく、FreeBSD 5.xとも全く異なる方針で開発されている。この例として、LWKTや軽量メッセージシステムが有る。このような多くの、DragonFly BSDに実装される、概念はAmigaOSに触発されている。DragonFly BSDには、最近の殆どのカーネルのように、ハイブリッドカーネルが採用されている。つまり、これは、モノリシックカーネルとマイクロカーネルの両方の性質を併せ持ち、必要に応じて両方のメリットを使うということである。例えば、マイクロカーネルのメッセージシステムにあるようなメモリ保護の恩恵を受けるのと同時に、モノリシックカーネルにあるような処理速度は残っている。メッセージサブシステムは、Machのようなマイクロカーネルのデザインと似て、余り複雑ではないものになっている。さらに、これは同期通信と非同期通信の両方に対応しており、状況に応じて最良の性能を出せるようになっている。デバイスI/OやVFSはメッセージサブシステムを使うように変更されている。これらの新しい機構に拠り、カーネルの様々な部分をユーザーランドで実行可能になる。ユーザーランドでカーネルの一部を実行すると、その部分はカーネルという大きなプログラムの一部ではなく、小さく独立した1つのプログラムとなる。こうすることで、ユーザーランドで動いているドライバーがクラッシュしても、カーネル全体はクラッシュしなくなるという利点も有る。システムコールはユーザーランド版とカーネルランド版に分けられ、メッセージとしてカプセル化されるようになった。これに拠って、標準システムコールの実体をユーザーランドにある互換レイヤーに移すときのプログラム量と複雑さを軽減可能になると同時に、新旧のDragonFly BSDの互換性を保ち易くなった。さらに、Linuxやその他のUNIX系OSのアプリケーションを動かすための機構もユーザーランドに移せる。このようなFreeBSD jail上に作られたネイティブなユーザーランド互換レイヤーを使うことで、UMLと同等のことができる。しかし、UMLと異なり、仮想化には実際のハードウェアと通信するための特別なドライバーを必要としない。なお、UMLはLinuxをポーティングしたもので、ホストOSのカーネルを別のハードウェアプラットフォームと見なす実装になっている。スレッドはCPUに強く結び付けられるというデザインになっていて、各々のCPUはそれぞれLWKTスケジューラーを持っている。なお、スレッドが勝手に動作するプロセッサーを変えることはできず、IPIメッセージを使った場合のみ別のCPUへとスレッドが移される。そして、CPUを跨ぐスレッドスケジューリングも非同期のIPIメッセージを送ることで行われる。この方法を使うと、スレッドサブシステムを綺麗に区切れるが、その利点は、SMPシステムにて複数のCPUのキャッシュに同一データが乗らない、ということである。これに拠り、システムの各プロセッサーがスレッドの実行のために異なったデータをキャッシュできるようになり、高い性能を出せる。LWKTサブシステムでは複数のカーネルスレッドに処理を分けるように実装された。これに拠り、複数のカーネル内タスクでリソースを共有することで生じる競合状態を無くせる。このようにCPU毎の局所性を保つようにするアルゴリズムでスレッドを分ける実装は略間違い無くDragonFly BSDに特有のデザインである。共有資源(ファイルやデータ構造体など)へのアクセスは、マルチプロセッサーマシーンで安全に動作させるためには、直列化されなくてはならない。こうすることで、スレッドやプロセスは同時に同じ資源を変更できなくなる。アトミック操作・スピンロック・クリティカルセクション・ミューテックス・直列化トークン・メッセージキューは全て同じ資源への同時アクセスを防ぐのに使える方法である。LinuxもFreeBSD 5.xも粒度の細かいミューテックスを使ったモデルを用いることでより高性能なマルチプロセッサーシステムを構成しているが、DragonFly BSDはそうではなく、複数のスレッドが共有リソースに同時にアクセスしたり変更したりするのを防ぐために、クリティカルセクションと直列化トークンを用いている。最近まで、DragonFly BSDもSPLを使っていたが、その部分はクリティカルセクションで置き換えられた。LWKTサブシステム・IPIメッセージサブシステム・新しいメモリアロケーターなどを含むシステムの中心的な部分の多くはロックしない。つまり、ミューテックス無しで動き、CPU毎に処理を行う。クリティカルセクションは局所的な割り込みから守るために使われ、CPU毎に処理を行う。これに拠り、動かされているスレッドはCPUを横取りされないことが保証されている。直列化トークンは他のCPUからの並列アクセスを防ぐために使われ、複数のスレッドで同時に保持される。この結果、それらのスレッドの一つが与えられた時間に処理を行うことが保証される。それゆえ、ミューテックスを持っているスレッドと違い、ブロックされていたりスリープしているスレッドは他のスレッドが共有リソースにアクセスすることを禁止しない。直列化トークンを使うことで、ミューテックスを使った場合のようなデッドロックや優先度の逆転を引き起こす状況を防げる。これに加え、複数のスレッドで共有するようなリソースを要求する長いプロシージャーの設計や実装をずっと単純にできる。直列化トークンの実装は最近のLinuxにあるRCUによく似たものに発展しているが、計算機内の全てのプロセッサーではなく同じトークンで競合しているプロセッサー同士が影響を受ける、という実装になっている。開発の初期段階では、スラブアロケーターが採用され、FreeBSD 4.xのカーネルメモリアロケーターから置き換えられた。これはメモリを割り当てるときに排他制御やブロック操作を必要とせず、MPSAFEである。SFBUFとMSFBUFが使われている。SFBUFは短い時間しか使わない単一ページのマッピングを操作するのに用い、必要ならそれらのマッピングをキャッシュする。これらの機構は単一のVMページで保持されているデータへの参照を補うために使われる。この単純で強力な抽象化に拠って様々なことが可能になる。例えば、sendfile(2)でのゼロコピーが実現されている。SFBUFはカーネルの様々な箇所で用いられる。例えば、vnodeオブジェクトのページャーやパイプサブシステム(XIOを用いた間接転送の場合)で広帯域な転送を行うために用いられる。SFBUFは単一のVMページでしか使えないために、MSFBUFSが短い時間しか使わない複数のページのマッピングを操作するのに用いられる。SFBUFの概念はのがsendfile(2)を書いたときに考案された。そして、この概念はとによって書き直された。また、MSFBUFはとにより考案された。DragonFly BSDは、現在では、x86(インテルとAMD)及びx86-64アーキテクチャーベースの計算機で動作する。これは単一プロセッサーもSMPも両方対応している。初期のDragonFly BSDでは、FreeBSDのportsをパッケージ管理システムとして使っており、NetBSDのpkgsrcはオプションとして使えるに過ぎなかった。しかし、DragonFly BSD 1.4からpkgsrcがシステムの公式なパッケージ管理システムとなった。これで、開発者は追加でインストールされるソフトウェアのアップデート作業から解放されることになった。また、この変更はpkgsrcの開発者がpkgsrcの移植性を高めるのにも役立った。DragonFly BSD 3.4より、新たなパッケージ管理システムとしてDPortsが導入された。DPortsはFreeBSDのportsをDragonFly BSDで使用できるようにする仕組みであるが、pkgsrcとDPortsを同時には使えない。システムコールとデバイスI/Oの実装はDragonFly BSDのスレッドメッセージングシステムを使うように変更されたが、これらは未だに同期して動作している。最終的には、全てのメッセージサブシステムを同期又は非同期のどちらでも動作するようにする予定である。ユーザーランドスレッドのサポートも今後のリリースの重要な課題である。DragonFly BSDでは、今のところ、N:1スレッドしか持っていない。これについては、開発当初から取り組んでおり、近代的なスレッド実装になる予定である。DragonFly BSD 2.0より、ファイルシステムとして、HAMMERを採用している。なお、HAMMERの後継として、HAMMER2の開発がによって主導されている。

出典:wikipedia