pthread地獄

952 ：名無しさん＠お腹いっぱい。：2006/10/29(日) 08:26:55

>>951
ありがたや～

同期を取る必要の無いスレッド同士だからデタッチにすべきだと思った。
デタッチするとスレッドの戻り値とかをOSが管理しなくていいから少し
は効率よくなるはず？ジョイナブルでも正常にリソースが解放されるのなら、
そもそもデタッチスレッドって何のためにあるの？

953 ：名無しさん＠お腹いっぱい。：2006/10/29(日) 08:48:48

joinするのも只じゃないってことじゃね？

954 ：名無しさん＠お腹いっぱい。：2006/10/29(日) 14:05:29

>>952
　デタッチなスレッドを使用する意味・・（私の場合です）

　やっぱり、同期は必要になります！？。例えば親子関係のスレッドで、
　子供）処理を終えると親に通知する。（mutexと条件変数を使って)
　親　）通知を受けるが常時待機はしていない。（別な処理をしている）
　こんな関係だと、もし親がjoinで待ってると別な処理が出来ない。この
　待機時間がロスタイムになる。
　最後に親が死ぬ時は、子供状態を記す管理簿の内容で、
　待機するか、即死ねる判断ができる。

　これを、ある社会生活をモデルにすると・・・
　２時間飲み放題（バイキング）とします。
　店側（親）、客（子）にします。
　客）自由に飲み食いします。（酔っぱらって時間の事忘れるかもしれません）
　店）客の利用時間を監視しつつ、料理の準備や雑用をします。
　　　そして、２時間経過したら　客に帰れ[pthread_kill(客、強制(9))]を
　　　通知します。もちろん、２時間以内に帰ってくれる客もいます。
　 # 客の意志を尊重しjoinで待ってると、経営が成り立ちません。ってか？

　
　

955 ：名無しさん＠お腹いっぱい。：2006/10/29(日) 17:14:09

>>953
>>954
大作やなあ

つまり第一にjoinはブロックされるから使用したくない。
でも、親子関係のスレッドで>>954のような処理をする場合でも
あえてデタッチスレッドにしなければならないのだろうか？という疑問が沸いた
ジョイナブルなままでもいい気がするんだけど、。

まあ精進しますわ　

956 ：名無しさん＠お腹いっぱい。：2006/10/29(日) 20:20:03

>>955
　954です。
　要求に合った動作ができれば、それでいいと思います。
　しかし、コストパフォーマンスを考慮すると
　そうも行かない場合があります。
　
　joinで待つ間、L2キャッシュを占有されてると迷惑な場合も
　あります。待つのもね。
　だから、用途次第だと思います。
　　

957 ：名無しさん＠お腹いっぱい。：2006/10/30(月) 18:32:39

＞　joinで待つ間、L2キャッシュを占有されてると迷惑
解る人居る？

958 ：名無しさん＠お腹いっぱい。：2006/10/31(火) 01:01:35

>957
まったく．
意味が掴めない．
詳しくお願いします．

959 ：名無しさん＠お腹いっぱい。：2006/10/31(火) 01:17:13

>>957-958
そういうときはスルー力を発揮しなきゃ。

960 ：名無しさん＠お腹いっぱい。：2006/10/31(火) 02:33:35

まさか
joinで待つ＝対象スレッドが終了するのをポーリングして監視
だと思ってるんじゃあるまいか

ごめん、スルーできなかった

961 ：名無しさん＠お腹いっぱい。：2006/10/31(火) 22:43:00

「スルー力」って書き込み自体をしないのが本質だと思います。
何かの記事を真に受けた伝道師みたいに思えます。

>>960
　そのポーリングは無意味で、joinの方がましですよね。

・・・
スレッドに対して、要求する処理が終了して～スレッド消滅までの時間
正確に測る方法が知りたいんですが、だれか知りませんか？

　

962 ：名無しさん＠お腹いっぱい。：2006/11/01(水) 00:30:51

＞　joinで待つ間、L2キャッシュを占有されてると迷惑

の意味を教えてくれ
>>960 じゃないんだよな？

963 ：名無しさん＠お腹いっぱい。：2006/11/02(木) 23:03:12

>>962
　L2キャッシュ・・・
　CPUを基点に、データ保存の媒体として、L1,L2キャッシュ（CPU内部）、
　メモリ、HDD等とあります。
　データへのアクセス時間が最速なのは、前者から順になります。

　そこで、A=A+１　と足し算したい場合、Aはどこに保存されてると
　早く計算できると思いますか？
　
　
　
　

964 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 03:20:01

はい、レジスタ！

965 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 03:54:08

スルーとしけばよかった（＞＿＜）反省

966 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 06:11:44

で？

967 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 08:02:55

俺はYahoo!のブリーフケースに保存している。

968 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 10:05:43

ブリーフへのアクセス時間が最速、それはブリーフケース

969 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 10:18:37

ブリーフケース、ベリーフケース、ベリーファスト！

なるほど

970 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 18:03:19

↑笑えるポイントは？

971 ：名無しさん＠お腹いっぱい。：2006/11/03(金) 20:33:29

三段活用だろ

972 ：名無しさん＠お腹いっぱい。：2006/11/04(土) 00:10:07

↑解説ありがと。

笑えないけど、笑ってあげよう。

973 ：名無しさん＠お腹いっぱい。：2006/11/09(木) 15:07:44

>>518 >>887 >>888
http://lists.freebsd.org/pipermail/freebsd-threads/2006-October/003771.html
読むと対抗意識持ちつつ仲よくやってるみたいね。

974 ：名無しさん＠お腹いっぱい。：2006/12/12(火) 02:40:09

以下は、sem_wait/sem_post を使って同時に 2 スレッドまでしか
走行できないように排他処理を行うテストコード。
これを linux の gdb(6.4.90 系) で実行すると、なぜか assert に
引っかかってしまいます・・・。
debian etch でダメ。なぜか vine4.0 だと問題なし。

#include <stdio.h>
#include <pthread.h>
#include <semaphore.h>
#define MAX_THREAD_NUM (2)
#define THREAD_NUM (8)
sem_t sem;
void thread_func(void *arg) {
int id = (int)arg;
int ret = sem_wait(&sem);
assert( ret == 0 );/* gdb だと謎エラー */
printf("%d start.\n", id);
sleep(1);
printf("%d finish.\n", id);
sem_post(&sem);
}
int main() {
int i;
pthread_t handle[THREAD_NUM];
sem_init(&sem, 0, MAX_THREAD_NUM);
for (i = 0; i < THREAD_NUM; ++i){ pthread_create(&handle[i], NULL, (void *)thread_func, (void *)i); }
for (i = 0; i < THREAD_NUM; ++i){ pthread_join(handle[i], NULL); }
sem_destroy(&sem);
return 0;
}

975 ：974：2006/12/12(火) 02:55:22

debian etch 、vine4.0 ともに gdb のバージョンは 6.4.90。
ということは libc のバージョンの差が原因なのか・・・。
なんにせよ、gdb 上でセマフォがさっぱり機能しないというのは
つらいです。

976 ：名無しさん＠お腹いっぱい。：2006/12/12(火) 08:12:05

謎つうかerrnoは見ないの？

977 ：名無しさん＠お腹いっぱい。：2006/12/12(火) 08:51:37

sem_initの戻り値をまず確認しないと。

978 ：名無しさん＠お腹いっぱい。：2006/12/12(火) 12:57:25

>>974
これが原因じゃないような気はするけど、念のため、
sleep(1)使うのやめてpoll(NULL, 0, 1000)にしてみたら？

あとは>>976に同意。

979 ：名無しさん＠お腹いっぱい。：2006/12/12(火) 13:08:45

「あとは」じゃなくて、まずerrno。

980 ：名無しさん＠お腹いっぱい。：2006/12/12(火) 13:47:09

細かい日本語のつっこみくらいしかできない人乙