共有資源(ファイルやデータ構造体など)へのアクセスは、マルチプロセッサーマシーンで安全に動作させるためには、直列化されなくてはならない。こうすることで、スレッドやプロセスは同時に同じ資源を変更できなくなる。アトミック操作・スピンロック・クリティカルセクション・ミューテックス・直列化トークン・メッセージキューは全て同じ資源への同時アクセスを防ぐのに使える方法である。LinuxもFreeBSD 5.xも粒度の細かいミューテックスを使ったモデルを用いることでより高性能なマルチプロセッサーシステムを構成しているが、DragonFly BSDはそうではなく、複数のスレッドが共有リソースに同時にアクセスしたり変更したりするのを防ぐために、クリティカルセクションと直列化トークンを用いている。最近まで、DragonFly BSDもSPLを使っていたが、その部分はクリティカルセクションで置き換えられた。LWKTサブシステム・IPIメッセージサブシステム・新しいメモリアロケーターなどを含むシステムの中心的な部分の多くはロックしない。つまり、ミューテックス無しで動き、CPU毎に処理を行う。クリティカルセクションは局所的な割り込みから守るために使われ、CPU毎に処理を行う。これに拠り、動かされているスレッドはCPUを横取りされないことが保証されている。直列化トークンは他のCPUからの並列アクセスを防ぐために使われ、複数のスレッドで同時に保持される。この結果、それらのスレッドの一つが与えられた時間に処理を行うことが保証される。それゆえ、ミューテックスを持っているスレッドと違い、ブロックされていたりスリープしているスレッドは他のスレッドが共有リソースにアクセスすることを禁止しない。直列化トークンを使うことで、ミューテックスを使った場合のようなデッドロックや優先度の逆転を引き起こす状況を防げる。これに加え、複数のスレッドで共有するようなリソースを要求する長いプロシージャーの設計や実装をずっと単純にできる。直列化トークンの実装は最近のLinuxにあるRCUによく似たものに発展しているが、計算機内の全てのプロセッサーではなく同じトークンで競合しているプロセッサー同士が影響を受ける、という実装になっている。
スレッドはCPUに強く結び付けられるというデザインになっていて、各々のCPUはそれぞれLWKTスケジューラーを持っている。なお、スレッドが勝手に動作するプロセッサーを変えることはできず、IPIメッセージを使った場合のみ別のCPUへとスレッドが移される。そして、CPUを跨ぐスレッドスケジューリングも非同期のIPIメッセージを送ることで行われる。この方法を使うと、スレッドサブシステムを綺麗に区切れるが、その利点は、SMPシステムにて複数のCPUのキャッシュに同一データが乗らない、ということである。これに拠り、システムの各プロセッサーがスレッドの実行のために異なったデータをキャッシュできるようになり、高い性能を出せる。LWKTサブシステムでは複数のカーネルスレッドに処理を分けるように実装された。これに拠り、複数のカーネル内タスクでリソースを共有することで生じる競合状態を無くせる。このようにCPU毎の局所性を保つようにするアルゴリズムでスレッドを分ける実装は略間違い無くDragonFly BSDに特有のデザインである。
DragonFly BSDには、最近の殆どのカーネルのように、ハイブリッドカーネルが採用されている。つまり、これは、モノリシックカーネルとマイクロカーネルの両方の性質を併せ持ち、必要に応じて両方のメリットを使うということである。例えば、マイクロカーネルのメッセージシステムにあるようなメモリ保護の恩恵を受けるのと同時に、モノリシックカーネルにあるような処理速度は残っている。メッセージサブシステムは、Machのようなマイクロカーネルのデザインと似て、余り複雑ではないものになっている。さらに、これは同期通信と非同期通信の両方に対応しており、状況に応じて最良の性能を出せるようになっている。デバイスI/Oや仮想ファイルシステム (VFS) はメッセージサブシステムを使うように変更されている。これらの新しい機構に拠り、カーネルの様々な部分をユーザーランドで実行可能になる。ユーザーランドでカーネルの一部を実行すると、その部分はカーネルという大きなプログラムの一部ではなく、小さく独立した1つのプログラムとなる。こうすることで、ユーザーランドで動いているドライバーがクラッシュしても、カーネル全体はクラッシュしなくなるという利点も有る。システムコールはユーザーランド版とカーネルランド版に分けられ、メッセージとしてカプセル化されるようになった。これに拠って、標準システムコールの実体をユーザーランドにある互換レイヤーに移すときのプログラム量と複雑さを軽減可能になると同時に、新旧のDragonFly BSDの互換性を保ち易くなった。さらに、Linuxやその他のUNIX系OSのアプリケーションを動かすための機構もユーザーランドに移せる。このようなFreeBSD jail上に作られたネイティブなユーザーランド互換レイヤーを使うことで、UMLと同等のことができる。しかし、UMLと異なり、仮想化には実際のハードウェアと通信するための特別なドライバーを必要としない。なお、UMLはLinuxをポーティングしたもので、ホストOSのカーネルを別のハードウェアプラットフォームと見なす実装になっている。
病弱のため大学進学は叶わなかった。日本で初めて京大に考古学教室を開いたことで知られる濱田耕作に師事し、多年にわたり日本ばかりでなく朝鮮、中国にて考古学の研究に従事し、功績を残した。型式学的研究法の確立で日本考古学に貢献した。個性的な性格のため、多くの同年代の考古学者（末永雅雄、小林行雄など多数）との確執を生んだ。門下生達との座談会での回想が、『東方学回想 IV 学問の思い出〈3〉』（刀水書房、2000年）に収録されている。
他の品種と同様、シュナン・ブランのワインの品質は、ブドウ栽培時の手の掛け方に密接に関係している。収穫時期が早すぎてブドウが十分に熟していないと、酸が多すぎるためワインは「最も不快なワイン」（ワイン専門家、オズ・クラークの評）になってしまう。収量が多すぎると、シュナン・ブランらしい個性の無いワインになる。ロワール地方では、フランスの法規制により収量は40～50 hl/haに抑えられている。このくらいの収量であれば、シュナン・ブランの特徴であるフローラルな香りや蜂蜜の香りが感じられる。カリフォルニアのセントラル・ヴァレーでは、平均1エーカーあたり10トン（175 hl/ha）もの高収量であるが、このような場合は香りは穏やかではっきりしないものになる。この品種は元来樹勢が強く、管理しないと収量が過剰になる傾向がある。南アフリカの一部地域のような肥沃な土地においては、240hl/haもの収量に容易に達してしまう。そのため、収量を抑えるために、ヴィティス・リペリア種やヴィティス・ルペストリス種の樹勢の弱い台木に接ぎ木することも行われる。過剰な果房を取り除くグリーン・ハーベストも採用されることがある。醸造に適した酸と糖分のバランスになるような最良の熟度で収穫を行うために、ブドウを順次収穫していくことも多くの生産者が実施しており、特にロワールで顕著である。この場合、4～6週間にわたってブドウ畑を3～6回ほど回り、熟したブドウの果房ないしは果粒だけを手摘みで収穫していくことになる。貴腐ワインの生産の場合は、十分な量の貴腐化したブドウがなくてはならない。気温が高すぎたり、乾燥しすぎているなどの理由で貴腐ブドウが生じなかった年は、ブドウが干からびたような状態になるまで木に生ったままにしておくパスリヤージュと呼ばれる手法を用いる。これにより、貴腐と同様に果汁が濃縮される効果がある。伝統的な産地においては、生産者はシュナン・ブランからどのようなスタイルのワインを作るか、甘口と辛口のどちらを作るか、さらには複数のタイプのワインを作るならどのブドウからどんなワインを作るかを日々の状況を見ながら決めていく。ヴーヴレの生産者の例では、1シーズンの収穫回数は6回に上るが、前半の収穫分ではスパークリングワインや辛口ワインを生産し、後半は甘口ワインの生産に使われるという。