Jumlah utas maksimum

Saya memiliki program yang menerima 2 N-digit angka, mengalikannya menggunakan utas & mencetak hasilnya.

Jumlah thread yang dibuat di sini adalah 2 * N - 1.

setiap kali saya menjalankan program untuk N > 151, program tersebut memberi saya kesalahan segmentasi.

Apakah ada batasan jumlah maksimum thread yang dapat diperoleh suatu proses dari kumpulan thread?

Jika ya, apakah ini bisa menjadi alasan yang sah atas kesalahan tersebut?

Sunting:

Valgrind tidak menemukan kebocoran memori untuk N <= 150.

Saya menjalankan program di kernel Linux 2.6.x.


c pthreads segmentation-fault
person Community    schedule 02.10.2010    source sumber

Jawaban (6)


arrow_upward
10
arrow_downward

Secara default, setiap thread mendapat tumpukan 8 MB. 300 thread kali 8MB sama dengan 2,4 GB hanya untuk tumpukan thread - jika Anda menjalankan dalam mode 32 bit, maka itu mungkin sebagian besar ruang alamat proses yang diizinkan.

Anda dapat menggunakan pthread_attr_setstacksize() untuk mengurangi ukuran tumpukan thread Anda menjadi sesuatu yang lebih masuk akal sebelum Anda membuatnya:

int pthread_attr_setstacksize (pthread_attr_t *__attr, size_t __stacksize)

(Buat pthread_attr baru, atur ukuran tumpukan lalu teruskan ke pthread_create).

person caf    schedule 02.10.2010
comment
Sekarang setelah saya periksa, pthread_create tidak mengizinkan pembuatan pthread ke-303, meskipun saya mengatur ulang ukuran tumpukan menjadi 80 byte. - person ; 02.10.2010
comment
Apakah ada batasan ukuran sumber daya lain yang juga harus dikurangi? - person ; 02.10.2010
comment
@crypto: Jika Anda mencoba mengurangi ukuran tumpukan di bawah PTHREAD_STACK_MIN (16384 di Linux), pthread_attr_setstacksize() akan gagal dan akan tetap menggunakan ukuran yang sama. Coba atur ke nilai yang layak, (mis. 65536). - person caf; 02.10.2010
comment
@crypto: Anda harus selalu memeriksa nilai kembalian dari fungsi yang Anda panggil, termasuk pthread_create() dan pthread_attr_setstacksize(). Ini akan menghemat waktu Anda dalam jangka panjang. - person ninjalj; 02.10.2010

arrow_upward
2
arrow_downward

POSIX menjamin Anda 64 thread. Lebih dari itu merupakan anugerah dari pelaksanaannya.

person David Schwartz    schedule 15.08.2011

arrow_upward
1
arrow_downward

Itu berarti lebih dari 300 thread! Pertimbangkan overhead besar dari prosesor yang terus-menerus berpindah di antara keduanya dan memprioritaskannya, serta thread dari aplikasi lain. Menurut saya penggunaan thread seperti itu adalah bencana yang menunggu untuk terjadi, dan mungkin juga tidak akan membantu kinerja Anda.

Saya menduga jumlah threadnya adalah jumlah maksimum, mengingat tugas CPU adalah mengelolanya. Saya tidak akan menggunakan lebih dari 100 utas, itu ide yang buruk.

person Alexander Rafferty    schedule 02.10.2010

arrow_upward
1
arrow_downward

Jika di Linux: Centang PTHREAD_THREADS_MAX di limits.h . Itu adalah maks. jumlah thread yang diizinkan per proses. Dan juga: ini seharusnya tidak menjadi penyebab kesalahan seg.

person Mario The Spoon    schedule 02.10.2010

arrow_upward
1
arrow_downward

Pertanyaan Anda tidak menentukan lingkungan operasi, yang diperlukan untuk dapat menjawab pertanyaan pertama Anda, tetapi jika Anda terikat dengan CPU dan jumlah thread yang Anda miliki melebihi jumlah inti prosesor (2 atau 4 pada sebagian besar notebook ), maka Anda mungkin membuang-buang sumber daya.

Untuk pertanyaan kedua, tidak, ini bukan alasan yang sah untuk kesalahan segmentasi. Anggaplah Anda membuat jumlah thread yang konyol ini untuk beberapa alasan bagus yang tidak kami sadari, periksa kembali penggunaan semaphore dan hasil alokasi sumber daya Anda.

person danorton    schedule 02.10.2010

arrow_upward
1
arrow_downward

Kotak Ubuntu saya menunjukkan batas 123858, jadi saya ragu Anda akan mencapainya dengan 300, tetapi pthread_create Anda akan mengembalikan bukan nol jika Anda melakukannya. Pastikan untuk memeriksa nilai pengembalian.

Kompilasi dengan -g dan jalankan dengan gdb untuk men-debug kesalahan segmentasi alih-alih menebak penyebabnya. Ini akan mengarahkan Anda ke baris yang tepat dan memberi tahu Anda nilai variabel yang tepat yang menyebabkan kerusakan.

Saya juga menyarankan kemungkinan masalah sinkronisasi seperti hilangnya mutex, tetapi jika itu penyebabnya, kemungkinan besar Anda akan melihat masalah dengan nilai N yang lebih kecil, meskipun tidak sesering itu.

person Karl Bielefeldt    schedule 02.10.2010