はい、それは可能であり、それはかなり頻繁に起こります。
OSは、CPU間で1つのスレッドを切り替えないようにします（スレッドの優先プロセッサの設定をより難しくするか、アフィニティを介して単一のプロセッサにロックすることもできます）。
Windowsのプロセスは、それ自体が実行ユニットではありません。この観点からすると、基本的にはスレッドのコンテキストにすぎません。
編集（さらなる説明）
「プロセスコンテキストスイッチ」のようなものはありません。基本的に、OSスケジューラは、プロセスに関係なく、「以前の」プロセッサがすぐに利用できない場合（アフィニティが許す限り）、（非常に適応性のある）ラウンドロビンアルゴリズムを介してスレッドを任意の空きプロセッサ/コアに割り当てます（つまり、マルチスレッドプロセスは、はるかに多くのCPUパワーを盗む可能性があります）。
この「ジャンプ」は、少なくともL1（場合によってはL2）キャッシュがコアごと（異なるスロット/パッケージプロセッサを除く）であることを考えると、コストがかかるように見えるかもしれませんが、「適切な」プロセッサを待機して機能しなくなることによる遅延よりも安価です。精巧な負荷分散を行うため（「ジャンプ」スキームによって可能になります）。
これはNUMAアーキテクチャには当てはまらないかもしれませんが、さらに多くの考慮事項があります（たとえば、すべてのメモリ割り当てをスレッドおよびプロセッサにバインドするように適合させ、可能な限り多くの状態/メモリ共有を回避する）。
アフィニティについて：スレッドごとまたはプロセスごとにアフィニティマスクを設定できますが（これはすべてのプロセスのスレッドの設定に優先します）、OSはスレッドごとに関連付けられた論理プロセッサを少なくとも1つ強制します（マスクがゼロになることはありません）。
プロセスのデフォルトのアフィニティマスクはその親プロセスから継承され（これにより、問題のあるレガシー実行可能ファイル用のシングルコアローダーを作成できます）、スレッドはそれらが属するプロセスからマスクを継承します。
プロセスのアフィニティー外のプロセッサーにスレッドアフィニティーを設定することはできませんが、それをさらに制限することはできます。
デフォルトでは、スレッドは使用可能な論理プロセッサ間をジャンプし（特に、生成したり、カーネルを呼び出したりする場合）、優先プロセッサが設定されている場合でもジャンプする可能性がありますが、必要な場合に限りますが、アフィニティマスク外のプロセッサ（かなりの遅延が発生する可能性があります）。
スケジューラーが物理プロセッサーとハイパースレッディングプロセッサーの違いを認識しているかどうかはわかりませんが、そうでない場合でも（私が推測しているように）、結果はほとんどの場合問題になりません。つまり、大きな違いはないはずです。スレッド数がまったく同じである場合、物理プロセッサまたは論理プロセッサを共有する複数のスレッド間。とにかく、このシナリオでは、主にSQLサーバーや.NETやJava VMなどの高性能で高度にマルチスレッド化されたアプリケーションでキャッシュスラッシングが発生するという報告がいくつかあります。これらのアプリケーションは、ハイパースレッディングをオフにすることでメリットが得られる場合と得られない場合があります。