プロセス仮想アドレス空間にある他のスレッドのスタックはどこにありますか？プロセスのセクションは（Linuxの場合）プロセスの仮想アドレス空間に配置されている場合

Question

には、以下の画像は示しています

あなたは、このプロセス以降（一つだけスタック部があることを見ることができる唯一の1つのスレッドがあると仮定します）。

しかし、このプロセスに別のスレッドがある場合、この2番目のスレッドのスタックはどこにありますか？それは最初のスタックのすぐ下にありますか？

Answer 1

私が覚えている限り、スタックを処理するためのスペースは、特定のスレッドによって使用される小さな部分に分割されています。間には偶発的な衝突を防ぐためのガードページもあります。そして、はい、スタックは他よりも下にあります。

Answer 2

新しいスレッドのスタックスペースは、親スレッドによってmmap(MAP_ANONYMOUS|MAP_STACK)で作成されます。つまり、ダイアグラムでは「メモリマップセグメント」に入っています。それは大部分のmalloc()が行くことができるところで終わることができます。

（MAP_STACKは、現在はノーオペレーションであり、将来のアーキテクチャでは特別な処理が必要な場合に備えて存在します）。

実際にスレッドを作成するthe clone(2) system callに新しいスレッドのスタックスペースへのポインタを渡します。 （いつでもマルチスレッドプロセスでstrace -fを試してみてください）。 this blog post about creating a thread using raw Linux syscallsも参照してください。

mmapingスタックの詳細については、this answer on a related questionを参照してください。例えばMAP_GROWSDOWNは、別のmmap()がスレッドスタックのすぐ下のアドレスを選ぶことを防ぐことはできません。したがって、メインスレッドのスタックのように動的に小さなスタックを増やすことはできません（カーネルはアドレス空間をまだマップされていません）。

したがって、mmap(MAP_GROWSDOWN)はスタックを割り当てるために設計されていますが、it's so bad that Ulrich Drepper proposed removing it in 2.6.29です。

---

また、メモリマップダイアグラムは32ビットカーネル用です。 64ビットカーネルは、カーネルメモリをマッピングするためのユーザ仮想アドレス空間を予約する必要がないため、amd64カーネル上で動作する32ビットプロセスは、4GBの仮想アドレス空間をすべて使用できます。 （NULLポインタデリファレンスは、実際に障害はないので、デフォルト（sysctlのvm.mmap_min_addr = 65536）による低64Kを除く。）

---

関連：

はpthreadsのためのスタックサイズについての詳細はRelation between stack limit and threadsを参照してください。 getrlimit(RLIMIT_STACK)はメインスレッドのスタックサイズです。 Linuxのpthreadは、新しいスレッドのスタックサイズとしてRLIMIT_STACKも使用します。