DCEThreadsはPOSIX Draft 4 スレッドの実装です。DCE は「分散コンピューティング環境」の略です[ 1 ]。DCEThreadsを使用すると、ユーザーは単一のプロセスで複数の実行経路を作成できます。[ 2 ]。pthreads インターフェースに基づいています。[ 3 ]
DCE/RPCは開発中だったが、当時POSIX委員会はPOSIXスレッドを最終決定していなかった。オープングループはどちらを使用するかを決定する必要があり、最終的に採用されたPOSIXスレッドは彼らが選択したものとは異なっていた。
POSIX Draft 4 のスレッドは当初から制限されていました(最終規格でこれらの制限は修正されました)。マイクロソフトは、Windows NT で DCE/RPC をMSRPCとして、またDCOMでも全面的に採用しました。プログラマーが DCOM サービスに関連して抱える安定性や信頼性の問題、特にメモリ リーク、例外処理の問題、スレッド キャンセルの安定性の問題のほとんどは、POSIX Draft 4 のスレッドの使用に起因しています。
DCE/RPCは非常に複雑なため、POSIXドラフト4のスレッド処理問題を解決し、最新化するには、高度なスキルと専門的なプログラミング知識が不可欠です。そのため、DCE/RPCのリファレンス実装は、その優れた機能にもかかわらず、情報とリソースの不足により開発が滞っています。
POSIX ドラフト 4 のスレッドと最終的な POSIX スレッド仕様の主な違いは、一部の関数が割り込み可能であるのに対し、他の関数はそうではないという点を除けば、スレッドのキャンセルです。DCE/RPC はスレッドキャンセルを利用して RPC の「リモート」全体にシグナルを伝播します。例えば、クライアント アプリケーションがスレッドを終了すると、サーバー上の対応するスレッドも同様に終了します。最終的な POSIX 仕様にはこのような高度なキャンセル方法は含まれておらず、Unix ベンダーが POSIX スレッド仕様を正しく実装するのに苦労したため、削除されました。
Linuxは、NPTLの導入とLinux 2.6カーネル以降、スレッドキャンセルを適切にサポートするようになった。
DCEThreadsは現在、実質的にはエミュレーションレイヤーとしてのみ存在している。