マルチスレッドプログラミング相談室

1 ：デフォルトの名無しさん：2001/08/09(木) 17:31

マルチスレッドプログラミング相談室

2 ：デフォルトの名無しさん：2001/08/09(木) 17:33

ブロードキャストプログラミング相談室

3 ：デフォルトの名無しさん：2001/08/09(木) 17:52

ピーコとおすぎのファッションプログラミング相談室

4 ：無党派さん：2001/08/09(木) 18:37

淀川長治の冥界ホモジニアス環境プログラミング相談室

5 ：デフォルトの名無しさん：2001/08/09(木) 19:02

g++でマルチスレッドなプログラムを書くときにオススメのクラスライブラリありますか？プラットホームはUNIX全般、
コーディング目的は暇潰しです

6 ：デフォルトの名無しさん：2001/08/09(木) 19:05

>>5
暇つぶしなら自分で作れば?

7 ：デフォルトの名無しさん：2001/08/09(木) 19:07

>>6
っすねー・・。

8 ：デフォルトの名無しさん：2001/08/09(木) 19:16

環境に依存しないネタでスレッドプログラミングについて
語りたいならJavaやC#やるのが手っ取り早い。

環境依存ならWindowsが一番楽しいかも

9 ：無党派さん：2001/08/09(木) 19:47

>>5
> g++でマルチスレッドなプログラムを書くときにオススメのクラスライブラリありますか？

http://lin.fsid.cvut.cz/~kra/index.html#QpThreadとか。

ただ、libraryがmultithread-safeじゃないし、

ちなみに*BSDやLinuxは、pthreadがマトモじゃないから、

> プラットホームはUNIX全般、

は面倒。場合によっては不可能。
どこが準拠じゃないかはそれぞれのlibraryのREADMEを。

10 ：デフォルトの名無しさん：2001/08/09(木) 22:25

MT-safeがしっかりしているライブラリが揃った環境って
どういうのがありますか？

11 ：デフォルトの名無しさん：2001/08/09(木) 22:42

フリーのOSで一番pthreadがちゃんと実装されてるのって何？
まさかLinuxの分けはないよね？

12 ：デフォルトの名無しさん：2001/08/09(木) 22:48

フリーの定義によってはSolaris？（笑

13 ：デフォルトの名無しさん：2001/08/09(木) 22:57

Javaスレッドプログラミング
http://www.shoeisha.com/book/Detail.asp?bid=9
http://g.oswego.edu/dl/cpj/
http://www.amazon.com/exec/obidos/ASIN/0201310090/103-8053412-8027047

漏れには難しすぎた・・・。
オライリーから出てるの買えばよかった・・・。

Concurrency: State Models & Java Programs
http://www-dse.doc.ic.ac.uk/concurrency/
http://www.amazon.com/exec/obidos/ASIN/0471987107/103-8053412-8027047

↑おもしろそう・・・。

14 ：デフォルトの名無しさん：2001/08/09(木) 23:04

>>11
FreeBSD3.xと、Linux2.0.xではLinuxの方がよかった。
IRIXもわりとしっかりしてた。
NetBSD、OpenBSDは全く知らん。
スレッドまわりは、OS・カーネル・ライブラリ（libcとか）での差が激しいので、
環境の違いが少ないWin32プラットホームが一番やりやすい。

15 ：デフォルトの名無しさん：2001/08/09(木) 23:05

やっぱりSolarisですか･･･

16 ：14：2001/08/09(木) 23:08

>>15 猛烈に同意。でも、Solarisはカーネル以外の部分を含んだシステムと
しては、使いづらい。

17 ：デフォルトの名無しさん：2001/08/09(木) 23:09

fork !!!!

18 ：デフォルトの名無しさん：2001/08/09(木) 23:11

Win32の話ですが
InterlockedIncrement()はなんでガードしないと行けないんですか？
４バイトのインクリメントならアセンブラでincとかになるから、
ﾛｯｸはいらない気がするんですが。

19 ：デフォルトの名無しさん：2001/08/09(木) 23:21

ちなみにLinuxのcloneって関数、あれforkなんでしょ？

20 ：デフォルトの名無しさん：2001/08/09(木) 23:29

>>18
たぶんX86以外のプラットホームで問題が起きるからでしょ。
X86ならメモリの値をインクリメントする命令があるけど
RISCはそんな複雑な命令なさそうだし。
winbase.hでもInterlockedIncrement()の定義の前は
---
#if (defined(_M_MRX000) || defined(_M_ALPHA) || (defined(_M_PPC) && (_MSC_VER >= 1000))) && !defined(RC_INVOKED)
---
ってなってるし。

21 ：デフォルトの名無しさん：2001/08/09(木) 23:55

一番揃ってるのはwin32っぽいですね。
unixだとスレッド使うよりpiped forkやIPC使ったほうがよさげな気がしませんか。

22 ：デフォルトの名無しさん：2001/08/10(金) 00:03

非Win32な環境でスレッドローカル変数を効率的に扱うにはどうすればいいでしょうか?
pthread_[gs]etspecificなんていちいちやってられないし…

23 ：デフォルトの名無しさん：2001/08/10(金) 00:03

windowsはプロセス起動がunixに比べて重過ぎるから、
仕方無くスレッドが発展したらしい>21

24 ：デフォルトの名無しさん：2001/08/10(金) 00:04

forkがcloneで実装されてるってだけですね

25 ：デフォルトの名無しさん：2001/08/10(金) 02:55

posixあげ

26 ：無党派さん：2001/08/10(金) 03:01

>>19
> ちなみにLinuxのcloneって関数、あれforkなんでしょ？

メモリ空間とか共有するリソースがあるfork。BSDのrforkに似ている。

で、threadは特殊なprocessだから、
signalのsemanticsがpthreadとちょっと違う。ただ違うのはここだけ。

linuxthreadsのREADMEより、
- Signal handling does not fully conform to the Posix standard,
due to the fact that threads are here distinct processes that can be
sent signals individually, so there's no notion of sending a signal
to "the" process (the collection of all threads).
More precisely, here is a summary of the standard requirements
and how they are met by the implementation:
(略)

*BSDよりはPOSIX conformance度は高い。

27 ：無党派さん：2001/08/10(金) 03:04

>>21
> 一番揃ってるのはwin32っぽいですね。

そんなことはない。スケジューラとか非常に貧弱。
POSIX 4相当(準拠でなくてもいいが)には全然足りない。

28 ：無党派さん：2001/08/10(金) 03:09

>>22
> 非Win32な環境でスレッドローカル変数を効率的に扱うにはどうすればいいでしょうか?
> pthread_[gs]etspecificなんていちいちやってられないし…

これは必要な時に使うもので、必要でなければ使わなければ良い。
どう利用するかによって、どうすればいいかは変わってくるから、
これ以上答えられない。

29 ：デフォルトの名無しさん：2001/08/10(金) 03:18

>>24
え？それはぎゃくじゃない？
sys_cloneからdo_fork呼んでるように見えるけど。
arch/i386/kernel/process.cなんか見ると。
おれの勘違いだったらごめん

30 ：デフォルトの名無しさん：2001/08/10(金) 08:54

>>27
スケジューラって具体的に何を指してますか？
あと、POSIX4相当であれば十分、というのは何を根拠にしてます？

自分が必要だなーと思う基準ですが:
- 周辺ライブラリ(libc含む)がMT-safeかどうかを考慮されたもので構成されているか
- それらがOSからのサポートを受けているものか(ユーザーが作ったwrapperではなく)
- それらの情報が揃っているか
- 実際に役に立つライブラリがあるか(藁

というのを考えると、一番win32、時点SolalisもしくはJava じゃないですかね。
単一ベンダが OS、開発環境、アプリケーション作ってりゃ当たり前なんですけども。

OSオタクでなく、実際にアプリケーションを書いている人の意見を求めます。

31 ：30：2001/08/10(金) 08:56

"であれば十分" → "であることが必要"
ですねスミマセン

32 ：デフォルトの名無しさん：2001/08/10(金) 09:31

>>13
その本面白そうだね。
Javaやる人って必ずGoFやると思うんだけど、
あれやっても構造に関しては一応それらしいものが作れるようになりましたって
なるけど、Javaの利点の一つのクラスにスレッドを簡単に割り当てられる、
これをどう活用したらいいのか？これにはあんまり参考にならないんだよね。

買ってみるかな。評者の★の数が全部満点なのがなんか怪しいがｗ

33 ：デフォルトの名無しさん：2001/08/10(金) 09:43

>>18
読み込み→インクリメント→書き込みのフェーズになるから、SMPではロックし
ないと他のCPUと競合する可能性がある。NTじゃなきゃ起きないけど。

34 ：無党派さん：2001/08/10(金) 13:12

>>30
> あと、POSIX4相当であれば十分、というのは何を根拠にしてます？

そんな事言ってない。「一番揃っている」のはwin32じゃないと言っただけ。
Solaris 8はPOSIX 4をほとんど実装しているが、win32はそうではない。

>>21
> 一番揃ってるのはwin32っぽいですね。

という文章に対してさ。

それ(一番揃っている)を要件にすると、

> というのを考えると、一番win32、時点SolalisもしくはJava じゃないですかね。

一番Solaris、次点win32、その他、
Javaはplathomeによる(VMの完成度が違うので)、じゃないかな？
(MacOS X, AIX, Tru64などマイナー系は省いた)

> というのを考えると、

って言ってるけど、新しく要件作れば、そりゃどんな順序にでも出来るでしょ。
俺は >>21の「一番揃ってる」に対して言ってるんだよ。頼むぜ。わけが分からん。
そもそも発端の >>11の"freeの"からも外れていってるしさ。

> スケジューラって具体的に何を指してますか？

スケジューラですけど？

>>30以外関心ないかも知れないのでsage

35 ：デフォルトの名無しさん：2001/08/10(金) 21:06

>>30の基準から考えるとマイナーながらBeOSが一番揃ってるね。

36 ：デフォルトの名無しさん：2001/08/10(金) 23:43

>>35
BeOSはあるバージョンアップのときに、大きな変革をやらかしたおかげで
既存アプリが大打撃を食らったそうだ。Mediaなんとかだっけかな。

そういう意味での安定性も必要だと思う。

37 ：デフォルトの名無しさん：2001/08/10(金) 23:44

>>34
POSIX準拠って何か役に立つの？
もしかして、すっげーくだんねえ話してる？

38 ：デフォルトの名無しさん：2001/08/11(土) 01:10

POSIXに準拠したスレッド、バリバリ使ったアプリとかあるの？
あるならおせーてくれ！

39 ：デフォルトの名無しさん：2001/08/11(土) 03:09

スレッドと言ったらやっぱりNTでしょ
Linuxは、スレッドは実装してないんでは???

40 ：デフォルトの名無しさん：2001/08/11(土) 03:35

POSIXは今後出てくる(であろう)OSに対する設計方針としての
標準インターフェイスを目指してるのかもしれないから、
既存のOSが準拠すべきものではないのかも。

POSIXに準拠していようがしてなかろうが、最終的にはその
実装、性能でしょ。SMPに対するスケジューリングの効率。
沢山プロセッサの乗ったマシンなんて使ったことないから
分からないけどNTのスケジューリング悪くないらしいよ。
聞きかじりの話だからあてにならないけどさ。

41 ：無党派さん：2001/08/11(土) 05:43

>>37
必要ない人は、別に気にする必要ないんじゃないの？
必要ない人に話しても(゜Д゜)ﾊｱ?でしょ。

>>40
SMPのscaleだけ話してるわけだよね。
それだけが要件の人は、それだけ考えればいいんじゃないのかな？
それだけを要件にしてもSolaris>>NTだけどさ。

けど、スケジューラの機能ってそれだけじゃあないよ。（1CPUの時でさえ）
NTの場合は、まともなdatabse構築する場合には、
kernelのsource codeが必要になって、スレッド関連だとスケジューラをいじることになる。

(゜Д゜)ﾊｱ?な人は必要ないということだから、この点について考える必要がない。
>>30が言っているように、判断は総合的にすればいい。

いずれにせよ、>>10,11にはSolaris, source code付きを勧めるよ。

http://www.sun.com/smcc/solaris-migration/docs/courses/threadsHTML/contents.html
http://www.sun.com/software/white-papers/wp-realtime/
このくらいは読んだ方がいいよ。> thread語りたい人

42 ：11：2001/08/11(土) 08:41

＞無党派さん
＞いずれにせよ、>>10,11にはSolaris, source code付きを勧めるよ。

どーもーです。
たった今からダウンロード開始します。
バイナリの方はインテル版だけですが･･･
ところでこれってFreeSolarisをダウンロードすれば
カーネルのビルドができるんですよね？

http://www.amazon.co.jp/exec/obidos/ASIN/0130224960/ref=pd_sim_fb_dp_1_1/249-1864945-9054761
ついでにこれも注文しました。

43 ：デフォルトの名無しさん：2001/08/11(土) 12:07

Sunはスレッドをsuspend/cancelしたがる癖があるんだよなあ。

pthreadでは穏やかになってるけど、いちいちcancellableかどうか調べるのか？
http://www.sun.com/smcc/solaris-migration/docs/courses/threadsHTML/cancel.html

Javaでもsuspend/cancelを導入した前科があるね。
http://java.sun.com/j2se/1.3/docs/api/java/lang/Thread.html

44 ：デフォルトの名無しさん：2001/08/11(土) 12:47

話変わっちゃうんだけど、自前でセマフォって作れるの？
俺、頭悪いから良く分からないんだけど、どうなの？

45 ：デフォルトの名無しさん：2001/08/11(土) 14:25

>>44
とりあえず入手が楽なlinuexthreadsかpmpthread(*BSD)のsourceでも眺めてみたら？
linuxthreadsにはsemaphore.cってのがあるよ。

46 ：デフォルトの名無しさん：2001/08/11(土) 14:38

>>43
Javaのthread仕様は、pthread規格策定時の研究が反映されてなかったね。

47 ：デフォルトの名無しさん：2001/08/11(土) 15:14

だれかソース見せてもらえませんか？

48 ：デフォルトの名無しさん：2001/08/11(土) 19:10

zthread はどうよ？
http://www.cs.buffalo.edu/~crahen/projects/zthread/

49 ：デフォルトの名無しさん：2001/08/12(日) 00:03

>>47
ブルドックが出てくるよ

50 ：デフォルトの名無しさん：01/08/29 23:03 ID:ufAQmXP2

signal()でSIGALRMを補足して関数を実行させる事を
マルチスレッドで行いたいのですが、うまくいきません。
スレッドではなくプロセスが補足してしまうからなのですが
これをスレッド毎に行う良い方法は無いでしょうか？
できれば参考となるソースが読みたいのですが
なかなかありません。

51 ：デフォルトの名無しさん：01/08/30 00:01 ID:C3TsWUik

>>50
OSは？thread libraryは何か分かる？

52 ：デフォルトの名無しさん：01/08/30 00:11 ID:MsTaBnpA

遅レスで C++ のライブラリ
http://www.cs.wustl.edu/~schmidt/ACE.html

53 ：50：01/08/30 08:25 ID:ZcipkBQk

>>51
OSはLinuxで、thread libraryは、POSIX.1c
です。

54 ：デフォルトの名無しさん：01/08/30 14:00 ID:C3TsWUik

>>53
> OSはLinuxで、thread libraryは、POSIX.1cです。

linuxthreadsなのかな？
linuxthreadsは、規約にあってないところがあって、それが >>50とも関連していると思います。
詳しくはREADMEをの最後の辺りを読んでください。>>26も。

それから、この制限はlinuxthreads自体に由来するのではなく、
clone(2)自体に由来しますから、他のthread libraryを使っても駄目です。
close(2)を使わないuser level threadであるpmpthreadsも芳しくありません。

55 ：IDEなんてクソ：01/08/30 22:01 ID:ZAelFQ6s

pthredとBSD系のシグナルは競合するから同時に使わない方がいい。
ついでに言うと、pthreadでシグナルは極力使わない方がいい。
どうしても使いたいときはシグナル受信スレッドをpthredのシグナル関数群を
使って実装して、他のスレッドはシグナルを受信しないようにマスクする。
このあたりはアスキーから出ている実戦マルチスレッドプログラミングを
熟読するとわかると思うよ。

56 ：デフォルトの名無しさん：01/08/31 01:50 ID:JrJLvbeM

>>55
> ついでに言うと、pthreadでシグナルは極力使わない方がいい。

つーか、かなり注意して使わないと、ってことじゃないかな。
同期し協調して動くthread群に、非同期で割り込んでくるわけだからね。
「どうしても」以下に書いてあるような工夫を応用毎に考えないと。

ダグ何とかさんのJavaのthreadの本もいいよね。高いレベルの設計話としては。

57 ：50：01/08/31 20:34 ID:rIUxoozo

>>51
>>54
>>55
>>56
返事遅くなりました。
情報どうもです。なるほど～、やっぱりマルチスレッドでの
シグナルは難しいしバグの温床にもなりやすいので
やらんほうがいいわけですね。私もあの後いろいろ
本を調べてみたのですが、シグナルハンドラ用のスレッド
を別途設けて他スレッドからのシグナルを全てその専用
スレッドで取り扱うようにするのが一般的みたいですね。
この場合不思議なのは、どのスレッドから発せられた
シグナルかを区別しないといけない場合どうやって区別
するのかということです。

58 ：：01/08/31 23:34 ID:K2I6K2jM

シグナルを受け取ったプロセスは、終了するのが基本だったんだけど
いつのまにか、プロセス間の通信に使われるようになって
おかしなことになってる。

59 ：デフォルトの名無しさん：01/08/31 23:34 ID:JrJLvbeM

>>57
> この場合不思議なのは、どのスレッドから発せられた
> シグナルかを区別しないといけない場合どうやって区別
> するのかということです。

signalはそういう機能(発信元告知)を提供してくれない。
けど、process内部のthreadからのsignalならば、
process内の事は自分で管理できるよね?

いずれにせよ、本当にsignal、つまり非同期的である必要があるのか?
必要があるとすれば、受け手側が割り込まれていいのはいつか?
signalは同時多発的に起きるかどうか?
なんて事を考えないといけないわけだけど、
よくよく考えると最後の部分は「割り込み」でやるんじゃなくて、
同期的にやった方が簡単だよね? (もちろんそれでいい場合は)
lockを保持したまま割り込まれちゃう事なんかを考えると。

pthread_cancelについて調べると、この辺の設計の指針が得られると思うけど。

> 本を調べてみたのですが、シグナルハンドラ用のスレッド
> を別途設けて他スレッドからのシグナルを全てその専用
> スレッドで取り扱うようにするのが一般的みたいですね。

となる理由も良く分かるだろうし。

60 ：これ定説？：01/09/01 00:05 ID:8UdnvL3A

Javaスレッドはクソ

61 ：５７：01/09/01 00:47 ID:YEBV7iy6

＞けど、process内部のthreadからのsignalならば、
＞process内の事は自分で管理できるよね?
ふむ、何となくわかった気もする。

＞pthread_cancelについて調べると
これ調べてみますです～。

62 ：IDEなんてクソ：01/09/01 01:11 ID:N2P03Y3g

ＵＮＩＸ歴長い人はすぐにシグナル使うけど、
マルチスレッドを使う場合は、極力シグナルを
使わない。素直にmutexを使った方がいいと思う。
プロセス間で通信する場合は、共有メモリでやれば、
シグナルより柔軟にできる。
それが難しいなら、マルチスレッドではなく古典的な
マルチプロセスでやったほうがいいよ。

63 ：デフォルトの名無しさん：01/09/01 01:40 ID:/npc6JZk

>>60
> Javaスレッドはクソ

メモリ管理しないでいいところとか、
VMに囲われていてOSのnative API使えないところとか、
thread programmingのいやらしいところに首突っ込まないですむから楽。

もちょっと過去の研究の成果を踏まえて欲しかった部分もあるけど。

64 ：デフォルトの名無しさん：01/09/05 22:39 ID:6B5pO.k2

>>60
定説。synchronizeキーワードが特に酷い。

いわゆる普通のthreadでなので、その点においては、
プログラミングの上で特に楽になるということはない。

むしろ中途半端な仕様のせいで混乱する可能性が高い(yieldのタイミング等)。
初心者には勧められない。

利用者に徹するなら問題ないと思うけど、それは他の言語(系)でも同じ。
提供者になるなら、標準パッケージのソースは一度見ておくこと。
嫌になるよ。

65 ：デフォルトの名無しさん：01/09/26 04:32

13の本はとってもいい本だったＹＯ

66 ：デフォルトの名無しさん：01/09/26 12:41

マルチたん・・・

67 ：デフォルトの名無しさん：01/09/26 16:01

>>64
>標準パッケージのソース
っていうのは、java.lang.Thread.javaのことではない?
見てみたら、nativeばっかりで、実体はわからなかった。
>synchronizeキーワードが特に酷い
というあたり、少し具体的に教えてもらえませんか。

68 ：デフォルトの名無しさん：01/09/29 00:24

>>67
>っていうのは、java.lang.Thread.javaのことではない?

たとえば、PipedInput/OutputStreamとか。

synchronizedについては...

1: protectedなメソッドが継承クラスでsynchronizedになっちゃった。
という状況で何が起こるか考えてみよう。

2: synchronizedで待ってるスレッドを中断させることができるか
できないか、について考えてみよう。

69 ：デフォルトの名無しさん：01/10/08 22:24

Σ（゜д゜ｌｌｌ）ガーン　　沈み掛けてる

70 ：デフォルトの名無しさん：01/10/08 22:42

>1: protectedなメソッドが継承クラスでsynchronizedになっちゃった。
>という状況で何が起こるか考えてみよう。
クラスを使うがわの認識不足でバグがでる可能性がある

>2: synchronizedで待ってるスレッドを中断させることができるか
>できないか、について考えてみよう。
プログラミングテクニックが必要だけど、できる

71 ：デフォルトの名無しさん：01/10/08 22:44

ファイルロック使うんだと。
ださすぎ。

72 ：デフォルトの名無しさん：01/10/08 23:23

>>70
synchronizedでlockを得られないで待っているスレッドを中断させる
のは一般には、できないことになってるけど、どうやるの？

73 ：デフォルトの名無しさん：01/10/09 23:58

javaさぱーりだけど興味有り監視中

74 ：デフォルトの名無しさん：01/10/10 09:54

wait/notifyを使ってsynchronizedと同等の動作を作り込んでやれば、待っているThreadの中断も可能。
っていみじゃないかな。

75 ：デフォルトの名無しさん：01/10/10 10:02

synchronizedで待っている、というのは大前提じゃないのか。
とりあえず、sage

76 ：デフォルトの名無しさん：01/10/10 10:14

>>74
wait/notifyは、そのオブジェクトのロックを持っているスレッドから
しか呼び出せない。つまり、synchronizedメソッド(ブロック)の中で
呼び出す必要がある。

77 ：デフォルトの名無しさん：01/10/10 10:20

synchronized ブロックの中で wait すればモニタ手放すんじゃ?
茶々気味だが...

78 ：デフォルトの名無しさん：01/10/10 10:24

つーか、wait/notify と Thread#interrupt() か。

79 ：デフォルトの名無しさん：01/10/10 10:43

>>74
> wait/notifyを使ってsynchronizedと同等の動作を作り込んでやれば、待っているThreadの中断も可能。
> っていみじゃないかな。
synchronizeキーワードは使うなって結論?

80 ：デフォルトの名無しさん：01/10/10 10:53

元の問題は、
>2: synchronizedで待ってるスレッドを中断させることができるか
だろ。
この意味は、synchronizedメソッドまたはブロックに入るために、
ロックの獲得を試みて、得られなく(他のスレッドが持っている)、
待っている、ということだよね。
こんな状況で、どうやってwait/notifyとかできるのよ。

81 ：デフォルトの名無しさん：01/10/10 11:02

だからモニタ持っているスレッドが wait すればモニタ手放して別の
スレッドが synchronized ブロックに入るじゃん。

82 ：デフォルトの名無しさん：01/10/10 17:26

ていうかマルチスレッド難しすぎ。
ここの人達がどれだけマルスレッド使いこなしてるのか疑問。

ていうか難しいと思ってるのは漏れだけかな(自爆

83 ：デフォルトの名無しさん：01/10/10 17:30

初歩的質問で悪いんだけど、マルチスレッドで気をつけることの、
・変数を保護しないと、途中で値が（他のスレッドにより）変更される事がある。
っていうのは分かるんだけど、
・リエントランスを防がなくてはいけない。
ってどういうことなの？

84 ：デフォルトの名無しさん：01/10/10 17:47

>>83
　状況をもっと書いてもらった方がいいと思うけど？

　リエントラントを許してもマルチスレッドにする方法はあるけど？

85 ：デフォルトの名無しさん：01/10/10 20:46

>>82
マルチスレッド自身は別に難しくもなんともないよ。
javaの実装がヘタレなだけ。

86 ：デフォルトの名無しさん：01/10/10 21:04

>1: protectedなメソッドが継承クラスでsynchronizedになっちゃった
そもそも設計ミスを言語仕様のせいにしてるところが問題なのでは？

>2: synchronizedで待ってるスレッドを中断させることができるか
できないけど
なんの問題もない

これが問題だと思ってるなら、才能が無いと思って
プログラマーやめた方がいいと思うよ

87 ：デフォルトの名無しさん：01/10/10 21:09

他人の設計ミスをかぶらなきゃいけない
締め切り間近の追いつめられたプログラマもいたりして

88 ：デフォルトの名無しさん：01/10/10 21:29

>これが問題だと思ってるなら、才能が無いと思って
>プログラマーやめた方がいいと思うよ

こんなことをいうのは802だけだから気にしなくていいよ

89 ：デフォルトの名無しさん：01/10/10 21:44

やめちまえ！！

なんか昔の職人さんみたいｗ

90 ：デフォルトの名無しさん：01/10/10 22:53

才能が無ければ普通はやめた方がいいと思うが
それとも、プログラミングが一番得意だったりして（笑）

91 ：デフォルトの名無しさん：01/10/10 23:10

じゃあ、802師匠は大学院生にもなって童貞ですけど男をやめたほうがいいのでしょうか？
それともオナニーが一番得意だったりして(藁)

92 ：デフォルトの名無しさん：01/10/12 21:19

板違いかも知れませんが御案内です。
クロスポストですみません。
今、801板で2ちゃんねるの有志が集まった同人ゲームの
開発が進んでいます。
801板住民で本気でボブゲを作るスレッド２
http://www2.bbspink.com/test/read.cgi?bbs=801&key=1001692226
主人公「ひろゆき」(名前変更可能) が周囲の少年・青年を
調教していく801Hゲームです。
現在、プログラムの方も募集中ですのでもし興味をもたれたら
のぞいてみてください。

93 ：デフォルトの名無しさん：01/10/13 16:19

磨・屡・稚・棲・麗・怒！

94 ：デフォルトの名無しさん：01/10/13 22:11

>>68
2についてはsynchronizedで待っているスレッドは原則として中断できない。
(Thread#stopで停止はできるが、これは危険!)
ただし、synchronizedとwait,notifyを使って中断可能な
mutexやセマフォを作ることは可能。
(当然synchronizedを使うが、どのような状況でもsynchronizedで長期間ブロックしないように実装すればよい)
...というのが正解。

1についてはsynchronizedメソッドをfinal指定するか、
もともとsynchronizedしなくてもいいように読み出し専用
オブジェクトにしてしまうというのも手だな。
java.util.Collectionsなんかがやってることも参考になるので見てみれ。

Javaスレッドの正しい使い方、問題点は以下のリンクを参照。
外人の言う事はためになるので読め。
http://www-6.ibm.com/jp/developerworks/java/010427/j_j-thread.html
http://www-6.ibm.com/jp/developerworks/java/010302/j_j-king.html

64はパッケージのソース見れって言うけど、
移植性の高いプログラム書こうという人は
そんなことしちゃいけないんだぞー

95 ：横槍君：01/10/13 22:48

synchronized
にしているってことは
その処理をしている間は他から一切いじられては困るはず

stopで強制終了させてしまうと触られてはまずい状態のまま
同期は解除されてしまう

とゆう単純なはなしですよね。

分かっててやるぶんには問題ないのだろうけど
ほとんどアプリの強制終了くらいにしか
おいらはうまい用途が思い付かない。
そんならexit()でいいじゃんってことに、、、

ところで自分はJavaのスレッドくらいしか知らないんだけど
世の中にはもっとスゴイ便利なしくみやライブラリが
ありそうなきがするです。

※のスレッドはほにゃららで凄いんだぜ
とかほげほげで便利だぜ
とかいうのを識者にぜひ自慢していただきたい所存

96 ：デフォルトの名無しさん：01/10/13 23:58

>>95
スゴイ便利な仕組みと言えば「セマフォ」
大昔からある同期機構なのに、これさえあれば
Javaのwait/notifyのようなことはもちろん、
mutexもリードライトロックも作れる。
できないのは、タイマーや、Javaで言うyieldみたいな
スレッドのスケジューリングに係わることかな。
それ以上のレベルのことをスレッドライブラリ自体に求める
必要は必ずしもないと思うが。
こういうことは、もっと上位のライブラリか
アプリケーションで実装すればいい。
足りないのは便利なライブラリではなくて、
並行プログラミングをちゃんと理解している人間の方。

余談だけどDBのトランザクションが一番身近で
スゴイ同期機構だと思うぞ。
厨房でも理解できるし。

97 ：デフォルトの名無しさん：01/10/14 00:09

Adaのランデブーよ、今こそ復活せよ！

98 ：デフォルトの名無しさん：01/10/14 00:44

>>94
>2についてはsynchronizedで待っているスレッドは原則として中断できない。
>(Thread#stopで停止はできるが、これは危険!)
Thread#stopで、lockの獲得を待っているスレッドを停止できる、とは言えないのでは？
例えば、スレッド１がロック１を持ち、スレッド２がロック２を持っていて、
スレッド１がロック２を獲得しようとして、同時にスレッド２がロック１を獲得しようと
する、いわゆるデッドロックの状態で、別のスレッドからスレッド１のstopを呼んでも、
スレッド１は停止(中断)しない。結局、デッドロックは解消しない。
元の問いが、synchronizedで待っているスレッドを中断する、ということだから、これは
stopでもできないというのが正解では？
mutexなどの利用については、その通りだと思うけど。

99 ：デフォルトの名無しさん：01/10/14 05:47

定説１:メインスレッドから複数のスレッドを呼んではいけない。
(Javaに限らず、パターンか何かでありませんでしたっけ？)

100 ：100get：01/10/14 06:06

>>99
え、そうなの？
ワーカースレッド（代表）経由で呼べって事かい？

101 ：デフォルトの名無しさん：01/10/14 10:32

>>98
もしかして、デッドロックが起こるような状況でしか
synchronizedで待つことはないと思ってる?

102 ：98：01/10/14 11:34

>>101
何かお互いに誤解があるようだね。
漏れは、「synchronizedで待つ」、の意味を、例えば、
　synchronized void doSomething(){}
というメソッドをあるスレッドが実行しようとして、thisのロックを他の
スレッドが持っているために、待たされている状況を想定している。
もちろん、ロックを持っているスレッドが、そのロックを手放せば、問題ないけど
そうでない場合に、どうか、ということ。
それ以外に、synchronizedで待つことを、問題にする理由がわからない。
synchronizedがロックの獲得を待つのは、問題、ではなく仕様。ただし、
タイムアウトの手段はない。例え推奨されないstopメソッドでもね。
デッドロックの例をあげたのは、この点を理解しやすいと思ったからだよ。
それを問題として捉えるかどうかだけど、タイムアウトが必要な場合は、
mutexとかで対応すればいい。
逆に、synchronizedの手軽さは、javaのメリット、というのが漏れの判断。

103 ：デフォルトの名無しさん：01/10/15 03:33

>>99

それはもしかして、

「ＵＩスレッドは出来る限りロックしてはならない」

という類のこと？

104 ：＿：01/10/15 15:38

Win32なんですけど、
MFC並みのC++用マルチスレッドライブラリって何かありませんか？

105 ：デフォルトの名無しさん：01/10/15 22:26

mfc並って、つまりなんもやってないどころかよけいな手間が増えるすばらしいライブラリがほしいのか？

素直にWin32 APIかpthreadつかえ。

106 ：デフォルトの名無しさん：01/10/16 01:47

CreateThreadってなんか継承とかあったりしてやたらめんどくさかった
記憶があり。ヘタレにはちとつらいな。

107 ：デフォルトの名無しさん：01/10/16 02:13

CreateThreadを直に使うことは普通ないと思う。

108 ：デフォルトの名無しさん：01/10/16 02:15

>>106
何を指して継承といってる?

109 ：デフォルトの名無しさん：01/10/16 06:52

ハンドルの継承でないの？

110 ：デフォルトの名無しさん：01/10/17 17:04

>>107 ばしばし使っとります。

111 ：デフォルトの名無しさん：01/10/17 20:22

MFC使ったってハンドルの継承の問題はあるぞ！

112 ：白痴：01/10/21 03:20

fork とスレッドは似たようなものだと思っていました age

113 ：デフォルトの名無しさん：01/10/21 03:23

>>110
C runtimeは一切使わないってことか・・・大変そう

114 ：デフォルトの名無しさん：01/10/21 03:27

C runtimeは不用意に使わないってだけだよ

115 ：デフォルトの名無しさん：01/10/21 03:29

浮動小数点も使わないとなるときついなあ

116 ：デフォルトの名無しさん：01/10/21 04:59

浮動小数点なんて使ったこと無い。
あったとしてもprintfの%出力ぐらいか。

117 ：デフォルトの名無しさん：01/10/21 05:05

TLSも不具合ありそう。

118 ：名無しさん＠Ｅｍａｃｓ：01/10/27 15:38

pthreadでさあ、read（などのブロッキングするシステムコール）してる
他のスレッドに割り込んでreadをやめさせたいときは、普通どうするの？

119 ：デフォルトの名無しさん：01/10/27 15:50

>>118
なんでread止めさせたいのか判らないです。

readして物理的な待ちに入ったら内部でスレッド切り替えてるけど？？

120 ：名無しさん＠Ｅｍａｃｓ：01/10/27 16:04

socketから情報がくることがあるからです。
pipe/select使えばいいのかな？
ちと面倒だけど。

121 ：デフォルトの名無しさん：01/10/27 16:07

pthread_kill( reader_thread, SIGINT )
じゃなくて？

122 ：デフォルトの名無しさん：01/10/27 16:08

>>120
shutdown()しちゃえばいいじゃん

123 ：名無しさん＠Ｅｍａｃｓ：01/10/27 16:25

殺したいわけではないです。
次に移らせたいのです。

pipe/selectでできましたよ。
これでいいのかな？

124 ：名無しさん＠Ｅｍａｃｓ：01/10/27 20:06

pthreadでWaitForMultipleObjects(いずれか)みたいなことって
どうやればできるんだろう。わからなくて泣きそう

125 ：デフォルトの名無しさん：01/10/27 21:10

>>124
無理。だからバカみたいにスレッドを増やすしかなかったりする。

126 ：デフォルトの名無しさん：01/10/28 03:28

>>125
pthreadってたいしたこと無いんだね。
俺が作ったマルチスレッドのアプリで
WaitForMultipleObjects使ってないものはない

127 ：名無しさん＠Ｅｍａｃｓ：01/10/28 09:21

WaitForMultipleObjects(すべて)なら簡単だけどね。

128 ：名無しさん＠Ｅｍａｃｓ：01/10/28 09:57

同じことで悩んでる人発見
http://cocoa.2ch.net/unix/kako/975/975847617.html

129 ：デフォルトの名無しさん：01/10/28 10:10

WaitForMultipleObjects(いずれか); って、例えばどういうときに
必要なんですか?

130 ：名無しさん＠Ｅｍａｃｓ：01/10/28 10:24

たとえば、入力ポートがいくつかあって、
どこかにデータが入ってきたら動作を開始するとか。

Win32のsignalオブジェクトに相当するものは
条件変数を使って簡単に作れたから、
WaitForMultipleObjectsに相当するものを汎用的に作るには、
そのsignalオブジェクトを使って
スレッド一つにつき一つずつただjoinするだけのスレッドを作って、
joinがすんだらシグナルを立てるようにすればいいのかな。

効率わる～
もっといい手はないのだろうか。

131 ：デフォルトの名無しさん：01/10/28 10:37

シグナル用のオブジェクトを Singleton にするんじゃ
だめなんか？

132 ：デフォルトの名無しさん：01/11/01 01:52

OpenMPっていうのはどうなの？
これってPthreadと似たようなものなんでしょ？
C++で書く事も前提になってるみたいなんだけど・・・

133 ：デフォルトの名無しさん：01/11/01 02:07

>>124-130
>>131 が正しい。スレッドが個々に Signal オブジェクトを
持つのではなく、単一の Signal オブジェクトに複数のスレッド
から notify を行うようにデザインする。

134 ：デフォルトの名無しさん：01/11/01 09:07

>>133
それだとスレッドがシグナルオブジェクトを知らなければならない。
もっとシンプルに～

135 ：デフォルトの名無しさん：01/11/01 09:31

>>134 スレッド開始前にシグナルを渡せば良いじゃん。

Thread t = new AbcThread(signal);
synchronized(signal){
　　t.start();
　　signal.wait();
}

てか、どこをどうシンプルにしたいの？
引数渡しすらやりたくないの？？？

136 ：デフォルトの名無しさん：01/11/01 09:34

スレッドってjavaだけじゃないし

137 ：135：01/11/01 09:39

複数スレッドで WaitForMultipleObjects 相当のコード:

Object signal = new Object();
Thread[] t = new Thread[10];
synchronized(signal){
　　for(int i=i; i<t.length; i++){
　　　　t[i] = new AbcThread(signal);
　　　　t[i].start();
　　}
　　signal.wait();
}

public class AbcThread extends Thread{
　　private Object signal = null;
　　public AbcThread(Object signal){
　　　　this.signal = signal;
　　　　return;
　　}
　　public void run(){
　　　　...
　　　　synchronized(signal){
　　　　　　signal.notifyAll();
　　　　}
　　　　return;
　　}
}

138 ：デフォルトの名無しさん：01/11/01 09:47

>>135
言いたいことは分かったが、
WaitForMultipleObjects(OR)みたいな美しさがなくていいなら、
pthread_cond_waitで十分できるので。

139 ：135：01/11/01 10:17

WaitForMultipleObjects がシンプルで美しいか？
まずそこら辺の美的感覚が違うな...。まぁ趣味的な
相違を深く突っ込む気もないので好きにしてくれ。

140 ：名無しさん＠Ｅｍａｃｓ：01/11/01 11:27

スレッドをWin32イベントとして扱えるのは素直に
美しいと思ったが、何か偏見があるのじゃないか。

141 ：デフォルトの名無しさん：01/11/06 21:14

sleep()をVC++6.0SP5（WinNT4.0SP5）でマルチスレッドで使ってるんです。
あるマシンではsleep(2)とかが正常に動作している
(PIOボードに出力させてそれをオシロで見た結果）
のに、別のマシンでは、小さな値を渡しても10msec以下になりません。
対処法ありますか？

142 ：デフォルトの名無しさん：01/11/06 21:19

timeBeginPeriod

143 ：デフォルトの名無しさん：01/11/07 00:27

WaitForMultipleObjectsだとすっきり、かつ、美しく書けるんだが
これに相当するもののない環境って意外に多い。というかwin32だけ？

144 ：デフォルトの名無しさん：01/11/07 02:38

threadが発達してるのはwinだねぇ。
そもそも、マルチスレッドがデフォルトっていう概念は、
winが最初じゃない？

145 ：デフォルトの名無しさん：01/11/07 03:09

>141
sleep()でmsecオーダーの動作を期待することがイタい。

146 ：デフォルトの名無しさん：01/11/09 01:26

スレッドを1msec未満の時間スリープさせるなんてことは
できるのでしょうか？
WinNT+VC++で

147 ：デフォルトの名無しさん：01/11/09 01:49

>>146
割り込みをマスクしてタイマーを監視してればいいだろうが、
システム全体がパフォーマンスダウンして不安定になるだろう。

148 ：デフォルトの名無しさん：01/11/09 01:51

NTで割り込みをマスクするってデバイスドライバでもムリかも。
何をやりたいのか書けば？>>146

149 ：デフォルトの名無しさん：01/11/09 01:54

いわゆるunixだとthreadは完全に後付けだね。
machが研究的にあれこれやってたみたいだけど、
実用OS上でインプリし、かつ実用しているのはwin32が最初かも。

150 ：デフォルトの名無しさん：01/11/09 01:57

そもそも一ミリ秒以下の間隔でデータの受信が
複数のデバイスで発生したときに、アプリが
割り込ませてくれなければ、ちゃんとシステムは動かない。
どうしてもやりたきゃネットワークもハードディスクも
ないワンボードマイコンでやるしかないだろうと思われ。

151 ：デフォルトの名無しさん：01/11/09 09:14

RS232Cで送受信できるプログラム作ってます
"123456789"のcharデータを送信するプログラムと
それをスレッドで受信するプログラムを使い、テストしました
結果は
123456789
12543789 123456
などスペースが勝手に入ったり、改行したりしなかったり
順番が入れ替わったりしました
正確な受信をすることはできるのでしょうか？
お願いします

152 ：146：01/11/09 11:55

言葉足らずですみません。
【目的】
あるスレッドでパルスモータをPIOボードを通じて回したい。
【課題】
PIOボードへの出力後、スリープさせたいが、
1msec単位でしかスリープできないと、回転速度をきめ細かく設定できない。

153 ：デフォルトの名無しさん：01/11/09 12:26

forkとスレッドって代替するものなの？
forkはもういらないって事？

154 ：デフォルトの名無しさん：01/11/09 12:53

>>153
んなこたぁない
forkの方が便利な場合も依然としてある

155 ：デフォルトの名無しさん：01/11/09 13:11

>>151
まずはスレッドを使わないでちゃんと受信ができているかテスト。

156 ：デフォルトの名無しさん：01/11/09 13:57

>>152
どう考えてもマルチスレッドの質問じゃないと思われ。

157 ：デフォルトの名無しさん：01/11/09 15:03

>>153
モジュール間の結合度が低くてデータのやりとりがIPCで十分な場合、
forkを使う方がいいと思ってる。

158 ：デフォルトの名無しさん：01/11/09 21:19

メモリ空間を共有するならスレッド。

159 ：デフォルトの名無しさん：01/11/09 23:33

>>152
分かってないなあ。
正確さをあきらめるならタイトループを
ベンチマーク的に測定してテキトーに。
たぶんきれいな方形波でなく、
不揃いのパルスになる。

正しくパルスを送るんなら、そのデジタルI/Oボードに
そのパルスを発生させるICを何とかして繋ぐのが正攻法。
H8なんかはPWMとRS232を内蔵していて便利。

160 ：名無しさん＠お腹いっぱい。：01/11/10 01:33

ちょっと古い話ですみません(>>18のWin32のロックについて)。

>InterlockedIncrement()はなんでガードしないと行けないんですか？

マルチプロセッサ環境で問題が出ます。
inc命令といってもリード/ライトサイクルがあり、その間に他のCPUが処
理する可能性があります。実際、マルチプロセッサマシンでそんな不具合
が起きそうなプログラムを書いて試してみてください。

非x86のときは、x86の命令に対応するものに展開される保障はありません
(＞20も少し触れている)。

161 ：デフォルトの名無しさん：01/11/10 05:19

>>157
やっぱマルチプロセスもいいよね。プロセスの死亡は痛くないけどスレッドの死は
痛い。あと信頼度の低いものをまとめあげるときには、疎な結合のほうが
いいから、プロセスを防波堤として使うのも好き。

にしてもマルチプロセスのときのプロセス間の連絡って皆どうしてんの？
POSIX IPC? System V IPC? pipe? socket?

それともRPC? またはCORBAとか分散オブジェクト使うの？

162 ：デフォルトの名無しさん：01/11/10 08:00

>>161
とりあえずsocket。

163 ：152：01/11/12 00:09

>156
言葉足らずでしたか。スマソ
ステッピングモータを回すスレッド以外に、通信や表示のスレッドがあって、
モータを回す際にスリープを正確にさせたい。

164 ：デフォルトの名無しさん：01/11/12 01:55

>>163
159みれ >>159

165 ：１５２：01/11/13 01:47

>>164
みたけどー。
要はmsec未満のスリープはできないのね。

166 ：デフォルトの名無しさん：01/11/13 02:14

>>152
そこまでの解像度を持つタイマが必要なら
もはやNTの出る幕ではないのでは…？
リアルタイムOSとか必要なんでは？よく知らんけど。

167 ：デフォルトの名無しさん：01/11/13 03:08

［参考］マイクロ秒単位の話：
以前NT用のセントロボードの読み出しドライバーで、
割り込みの奴とストローブをCPUで監視する奴の2種類
付属している奴があった。
その注意書きに、割り込みなしの奴は取りこぼしあり
とあり、保証なしだが、全く使えないわけではなく、
テキトーもありなんだとちょっと感心した。

168 ：デフォルトの名無しさん：01/11/13 14:49

マルチメディア系のライブラリなら、
マイクロ秒単位でタイマーの監視は出来そう
でも、それをやるとCPUがそれにかかりきりで、
ほかのスレッドを動かせなかったりするんでは。

169 ：デフォルトの名無しさん：01/11/13 15:41

>>166
だから>>159見ろと何度も言われてるのに取り合わない馬鹿は
ほっといて勝手に困らせとけ。

170 ：デフォルトの名無しさん：01/11/13 17:52

>>169
165に見たと書いてるけど。。

171 ：デフォルトの名無しさん：01/11/15 00:51

>169
ただのヴァカ

172 ：デフォルトの名無しさん：01/11/15 03:13

いにしゃらいずくりちかるせくしょん

173 ：かなみ：01/11/15 09:14

複数のスレッドから同じ関数を呼び出しちゃマズイですか？
関数内ではstaticな変数は使っていないんですが、、、

174 ：デフォルトの名無しさん：01/11/15 10:45

基本的にはなんら問題ない。競合問題というのはデータに対して起きるもので、
コードに対して起きるものではないから。
実は同じオブジェクトを引数に渡してて、そいつが競合してるとか?

175 ：かなみ：01/11/15 11:11

ありがとうございます。
大丈夫なんですね。

176 ：名無しさん＠ＸＥｍａｃｓ：01/11/15 12:23

>>173
> 関数内ではstaticな変数は使っていないんですが、、、

MT(multi-thread) safeな関数しか呼び出しちゃ駄目よーん。
例えば、UNIXだとgethostbynameはMT-safeじゃない。
gethostbyname_rがMT-safe版。

177 ：デフォルトの名無しさん：01/11/15 13:06

>>176
呼び出す周囲をMutexでくるむという手もある
すべての箇所で出来るという保証があればの話だが

178 ：デフォルトの名無しさん：01/11/15 14:27

>>173
別にマズくないです。
同じメモリ領域に、複数のスレッドで同時に書き込んだり、
あるスレッドから書き込むと同時に別スレッドで読み込んだり、
しない限り全然大丈夫です。

179 ：かなみ：01/11/15 16:32

「同時に同じ領域へアクセスしなければ特に排他処理をしなくても問題ない」
と理解しましたが、それでOKですか？

180 ：デフォルトの名無しさん：01/11/15 16:55

>>176
たまに表示が化けたり原因不明のエラーを出すの得意だろ

181 ：デフォルトの名無しさん：01/11/15 19:51

>>179
同時に読み出しだけならＯＫです。
書き込みが混じるときは気を付けましょう。

182 ：デフォルトの名無しさん：01/11/16 00:03

>>177
ラッパー関数かけ。

183 ：デフォルトの名無しさん：01/11/16 00:17

便乗で質問させてください。
時刻の取得⇒文字列として表示、にlocaltime, ctimeを使おうと思ったのですが
スレッド安全ではないために、localtime_r, ctime_rで記述しました。

ところがコンパイルは通るものの、実行すると上記箇所にて
coreを吐いて死んでしまいます。
(localtime, ctimeで記述時の動作は、期待通りです）

Solaris8, gcc295を使用しているのですが、
"*_r"関数には、何かしらの制限等があるのでしょうか？

184 ：デフォルトの名無しさん：01/11/16 00:21

取得から表示（もしくは中身のコピー）をするまで、クリティカルセクションで挟んどけ。
mutexでもいいぞ。

185 ：デフォルトの名無しさん：01/11/16 00:34

>>183は単にメモリを確保してないと思われ。

186 ：デフォルトの名無しさん：01/11/16 01:01

萎えるな、それ。

187 ：デフォルトの名無しさん：01/11/16 02:30

>>183
とりあえず「スレッドセーフ」って読んだほうが良いかと...。
>>179
どういう構造でmulti-threadが実装されているのか理解するまでは
愚直に危うそうな資源を排他するのをおすすめします。
「同時に同じ領域へアクセスしなければ特に排他処理をしなくても問題ない」
という表現に危うさを感じます。
たとえば、排他をしないでどうやって同時でないことを保証しましょう？

188 ：名無しさん＠ＸＥｍａｃｓ：01/11/16 03:31

>>179
マルチスレッドセーフって概念も理解したかどうか不安。

>>180 何でしょ？なにか用ですか？

189 ：デフォルトの名無しさん：01/11/16 03:38

localtimeもctimeもスレッドセーフだと思うのは俺の気のせいか？

190 ：デフォルトの名無しさん：01/11/16 04:56

*_rは、結果文字列バッファを引数で渡すので、ちゃんと確保してればスレセーフ。

フツーのlocaltimeとかctimeとかは、ライブラリ内部の？共通バッファに
結果を展開するので、別のスレで使われると、書き換えられる可能性がある。
ということじゃなかったかな？

まあ、あんまりセーフかどうかを気にしなくてもいいのかもしれんが、建前上はスレセーフではない。

191 ：_：01/11/16 05:10

VCだと*_rがないけど、マルチスレッドライブラリのリンクで
保障されるのかな

192 ：183：01/11/16 10:07

皆様のご指摘どおり、メモリを確保していないために
起きた現象でした。

メモリ確保をすることによって無事解決をしました。
ありがとうございます。

メモリを確保する必要があるのですね、知りませんでした。
その必要性は、以下のような解釈でよろしいですよね。。。

localtimeは、関数内static領域を保持することを前提に設計された関数であり
localtime_rは代替関数である。この関数はライブラリ内部の共通バッファを
使用しないことによってスレッドセーフを実現しているため、当然
自前でメモリを確保する必要性がある。

193 ：デフォルトの名無しさん：01/11/16 10:22

>>191
VC++の場合、マルチスレッド用のランタイムは内部で
動的なバッファを確保してる。

194 ：デフォルトの名無しさん：01/11/16 13:18

VCはランタイムライブラリの持つグローバル変数は全部TLS（スレッドローカル領域）
なので、大丈夫だよ。>>191

195 ：デフォルトの名無しさん：01/11/16 14:46

全部じゃないだろ。そんなことしたら排他制御もできん。

196 ：デフォルトの名無しさん：01/11/16 15:21

排他制御はOSの機能でやってるんでしょ
ま、「全部」ではないと思うが

197 ：デフォルトの名無しさん：01/11/16 16:40

質問よろしいでしょうか？
常駐処理をスレッドで作成しています。
スレッドが終わった場合に、もう一度起動するように
しようとしているのですが、
終わった筈のスレッドなのにGetExitCodeThreadでのコードが
STILL_ACTIVEになってしまいます。
何かおかしいでしょうか？コードは次のようなものです。
よろしくお願いします。

void main()
{
　　～略～
　while(1)
　　GetExitCodeThread( (HANDLE)hThread, &ExitCode );
　　if( ExitCode != STILL_ACTIVE ){
　　　　hThread=_beginthread( ThreadProc, 0, (VOID *)NULL);
　　}
　}
}

void ThreadProc( void *p )
{
　　/*処理*/
　　return;
}

198 ：デフォルトの名無しさん：01/11/16 16:46

mainもThreadProcも戻り値必須だボケ

199 ：194：01/11/16 21:04

>>195 全部ってのは言いすぎでしたん。ｽﾏｿ

200 ：デフォルトの名無しさん：01/11/16 21:07

てか、ちゃんとスレッドプロシージャの型を見ような。
cdeclとstdcallとではスタックの解放の仕方が違うんだよ。
大方、リターン直後でスタック破壊を起こしていると思われ。

201 ：デフォルトの名無しさん：01/11/17 03:00

>>192=183
ちょっと話題がずれるけど、ポインターをやりとりする時に
実態の領域を誰が用意するかはドキュメントを読まないと
判らないのはC言語の限界ですよね。。。
用意するにしても、領域の大きさも表現できないし。
>localtime_rは代替関数である。
代替かなぁ？
localtimeの仕様が気に入らない人が多くって、
thread-safeにするついでに関数の定義を直しちゃったとか？

202 ：デフォルトの名無しさん：01/11/17 09:28

>>201
sprintf→snprintfという変化もあるよ
thread-safeとはまた別に。

203 ：名無しさん＠ＸＥｍａｃｓ：01/11/18 02:45

>>201
> thread-safeにするついでに関数の定義を直しちゃったとか？

1. 仕様を変えないとMT-safeにならない。
2. 勝手にmallocするようにしないとMT-safeにならない。

という究極の選択で、1を選んだという事。
Lisp, Java, C#が2を選んで、

> 実態の領域を誰が用意するかはドキュメントを読まないと
> 判らないのはC言語の限界ですよね。。。

を克服するためにGCを採用した(知る必要なし)のはご存知の通り。

204 ：デフォルトの名無しさん：01/11/18 06:07

>>194-196
thread safeじゃない物はstruct _tiddataでまとめてTLS管理してる
ようだが。crt/src/mtdll.h辺り参照。

205 ：デフォルトの名無しさん：01/11/19 20:06

Windows＆VC++環境で親スレッドから子スレッドを終了したいのですが、
どうしたらいいので良いでしょうか？
自分で調べた中では、自分自身(呼び出し元)を終了させる方法しか
見つかりませんでした。

206 ：デフォルトの名無しさん：01/11/19 20:40

誰かが（親でも子でも、別EXEでも）社内掲示板（同期オブジェクト）を使って、リストラの通知をする
↓
仕事しながらたまに社内掲示板を待ち時間ゼロとかで調べる
↓
終了通知が来てたら、仕事を辞めて首をつる
↓
スレッドハンドルとかを待機して解雇を確認する
スレッドハンドルで解雇の確認ができないときは、死に際に
遺書（同期オブジェクト）を残す
↓
解雇完了

207 ：デフォルトの名無しさん：01/11/19 21:09

TerminateThread

208 ：デフォルトの名無しさん：01/11/19 23:14

だせーよおまえ

209 ：デフォルトの名無しさん：01/11/20 00:56

>>207
どうもです。
TerminateThreadについては、参考書に例として載っていましたが、
リスキーなので使わない方が良いと書かれていました。
他に安全な方法は無いでしょうか？

210 ：デフォルトの名無しさん：01/11/20 00:59

>>206をよく見なさい

211 ：デフォルトの名無しさん：01/11/20 01:03

>>209
206の解説：子供スレッドはある変数を監視し、それがある値に
なったら終了するようにしておく。親スレッドは、終了させたく
なったら、その変数をセットする。

当然だけど、子供スレッドは定期的にその変数を監視しないといけない。
かなり面倒。通信量が少ないなら別プロセスのほうが楽かもね。

任意のタイミングで無理矢理殺せるスレッドライブラリは少数派。
つかSolaris以外に知らない。

212 ：デフォルトの名無しさん：01/11/20 03:22

>>211
>任意のタイミングで無理矢理殺せるスレッドライブラリは少数派。
ただのpthreadでは...。(普通のUNIXで採用しているthreadね(かなり略))

213 ：デフォルトの名無しさん：01/11/20 03:24

単純に終了のための変数参照でもいいし
メッセージループと同様の作りでもいい、こっちの方がメッセージ
遅れるので融通利く

214 ：デフォルトの名無しさん：01/11/20 04:06

みなさんinet_ntoa()ってどうしてます？
私は代替にスレッドセーフなやつを適当に
自作してつかっちゃってるんだけど・・

215 ：：01/11/20 04:19

俺はinet_ntop()を使うようにしてる。ついでにv6対応にして(ﾟдﾟ)ｳﾏｰ。

216 ：デフォルトの名無しさん：01/11/20 09:49

通信デバイスにアクセスすると、たまに「ERROR_OPERATION_ABORTED」という
エラーが返ってくるんですが、これってどんなことが起こってて、どう解決していけば
いいのでしょうか？

VC++なんか初めてなのにマルチスレッドのプログラムのデバッグやらなきゃ
いけなくてヘルプ見てももうさっぱりです。
他のスレッドが使っているのだろうか？などとも考えたのですがそれをどうやって
調べればいいのかもわからないです・・・

ホントどうしようもなくシロートで申し訳ないんですが、よろしくお願いします。

217 ：デフォルトの名無しさん：01/11/20 10:57

>>214
WindowsNT以降ではinet_ntoaはスレッドセーフ(同じスレッドで再度Winsock関数が呼び出されるまで返された文字列は有効)だ。strtokも同様。

218 ：デフォルトの名無しさん：01/11/20 23:36

>>212
そのpthreadはニセモノだね。

219 ：デフォルトの名無しさん：01/11/20 23:37

普通のunixで採用しているthreadって何？

220 ：デフォルトの名無しさん：01/11/21 00:20

>>211
解説どうもです。
>>213
やっぱり、皆さんの提案されるような小技をつかわないと実現できない
のでしょうか？
シンプルに命令一つで実現できないものかと調べています。
あっても良さそうな命令なんですが、やっぱ別スレッドを終了させると
言う事はあまり良くない事(いろいろと問題がある)なのでしょうか？
仕様上、今の所は別プロセスを作る事は考えていません。

221 ：名無しさん＠ＸＥｍａｃｓ：01/11/21 00:50

>>220
> シンプルに命令一つで実現できないものかと調べています。

何作ってるか書かないと、
そのthreadが取得しているlockはどうするんだ？
とかいうアドバイスをしにくいぞ。

222 ：デフォルトの名無しさん：01/11/21 00:55

スタック以外何も占有していなければ、外部からTerminateしても問題なし。
そのスレッド内で使用するあらゆるリソースのためのマネージャを、メインスレッドが管理すればいい。
ただし、トランザクション中だけ、メインスレッドが待機する仕組みを必要とする。

で、そういうプログラムを以前1回仕事で作ってみたけど、問題なく動いてはいるね。
（子スレッドが使用するリソースがある程度限定できたからだけど。）

223 ：デフォルトの名無しさん：01/11/21 01:18

>>220
理解しやすいように具体例を挙げると、こういうことです。
次のようなスレッドがあるとします。

void thread()
{
　FILE* fp = fopen("a.txt", "r");
/*ここで色々な処理をする*/
fclose(fp);
}

メインスレッドからこのスレッドを終了させようとする場合、
このスレッドは、まだ処理実行の途中ですよね？
スレッドを途中で終了させたら、fclose は実行されないですよね？
困りませんか？

ここでfcloseが確実に実行されるためには、

(1) メインスレッドで fclose を実行する
(2) 子スレッドが自分で終了処理して fclose を実行する

のいずれかですが、FILE* fp がローカル変数だったら、
メインスレッドからファイルを閉じる方法は実行不可能です。

メインスレッドから子スレッド終了させると、
子スレッドは fclose を呼ぶヒマなく終了させられますからダメです。

そーすると、終了フラグを立てるなりして
子スレッドが自主的に終了するよう仕向けるしかないわけです。

おわかり？

224 ：デフォルトの名無しさん：01/11/21 02:40

>>222
但し書きのないいつ殺してもいいスレッドなんて
業務プログラムでは皆無だな（藁

ゲーム系ならあるのか？

225 ：デフォルトの名無しさん：01/11/21 02:44

>>220
残念ながら命令ひとつてポンってのはないよ。

スレッド管理をしてくれる魔法のつえなんてどこにもない。
ほとんどの場合同期処理が絡んでくるから、
設計は慎重に、コーディングは明快かつ丁寧にやるように。

226 ：２１２：01/11/21 02:54

>>218
>そのpthreadはニセモノだね。
(単語の認識に違いがあるかもしれませんが、)
pthread_kill()は意図した動作と違うのでしょうか？

227 ：デフォルトの名無しさん：01/11/21 02:58

pthread_kill()
send a signal to a thread

SYNOPSIS
#include <pthread.h>

int pthread_kill(pthread_t thread, int sig);

DESCRIPTION
The pthread_kill() function is used to request that a signal be delivered to the specified thread. As with kill(), if sig is zero, error checking is performed but no signal is actually sent.

228 ：２１２：01/11/21 03:14

>>227
マニュアルは私も引けるのですが、意図はいかがなものでしょう？
「任意のタイミングで無理矢理殺せるスレッドライブラリ」は
ニセモノ？ホンモノ？

229 ：デフォルトの名無しさん：01/11/21 03:16

227をどう読むと「無理矢理殺す」になるの？

230 ：デフォルトの名無しさん：01/11/21 03:20

>>228
pthread_killを使えばシグナルを遅れるが、
受け取り側のスレッドが正しくシグナルを処理できないと、
後で悲惨な目に遭うよ。

231 ：２１２：01/11/21 03:21

>>229(=227?,=218??違うかな？)
UNIXではSIGKILLを送ればシグナルのハンドルできずに終了です。

232 ：デフォルトの名無しさん：01/11/21 03:23

212がニセモノというオチだったのか

233 ：２１２：01/11/21 03:27

あう？
言われていることの意味がわからんです。
そろそろ眠いけど、教えてほしいです。

234 ：デフォルトの名無しさん：01/11/21 05:54

元質問者はWinのはずなのになぜpthreadの話になってる？

235 ：デフォルトの名無しさん：01/11/21 11:59

>>221-225
どうもありがとうございます。

> 何作ってるか書かないと、そのthreadが取得しているlockはどうするんだ？
> とかいうアドバイスをしにくいぞ。
はい、其の通りですね。情報が少なくてすみませんでした。

１つのプロセスがあり、親スレッドと子スレッドが常駐しています。
子スレッドでは通信処理(無限ループ処理で、イベント待機していて
イベントが発生すれば通信を行う)を行っています。

今、考えている流れは、
1)メインプロセスから、このプロセスに終了の依頼(アプリ終了処理依頼)
　↓
2)親スレッドが子スレッドに終了依頼をかける
　↓
3)子スレッド内の処理で通信中であっても通信を強制的に終わらせて
　子スレッドを正常に終了させる。(ローカル変数もろもろを全て開放)
　※但し、通信中の内容については保証しなくても良い。
　↓
4)親スレッドから子スレッドが正常に終了したのを確認した上で、親スレッドを終了。

要は、子スレッドにおいて通信処理を行っている最中に割り込みをかけて
子スレッドを終了したいと考えています。

＜現在＞
子スレッド(無限ループ)
・イベント待機
・・イベント発生⇒通信処理

＜変更＞
子スレッド(無限ループ)
・終了依頼チェック
・・終了依頼あり⇒子スレッド終了
・イベント待機
・・イベント発生⇒通信処理

上記のようにも考えてみたのですが、これだと終了依頼をかけても通信中の場合だと
通信が完了して、ループが先頭に戻ってくるまで終了できません。通信中であっても
すぐに子スレッドを終了させたいと考えています。(通信内容については保証しなくて
もいい)
以上、よろしくお願いします。

236 ：デフォルトの名無しさん：01/11/21 12:20

なんと言うかスレッドの問題じゃなくて非同期通信にしろってだけじゃないのか？

237 ：　：01/11/21 12:21

親スレッドで通信のイベント感知して、
スリープしておいた子スレッドを起こした方がよくない？

238 ：デフォルトの名無しさん：01/11/21 12:38

Windowsはよくしらんけど、もしpthreadなら上にでてるpthread_killでいいじゃん。
SIGALRMを送って、子スレッドの関数がEINTRで返ったのをみて
終了すればいいような…

239 ：デフォルトの名無しさん：01/11/21 12:38

>>235
窓だったら子スレッドをMsgWaitForMultipleObjects使わせて待機させ、
親スレッドは子スレッドにメッセージを投げることで終了依頼とする
通信を完全に非同期で行なえばメッセージを待つだけでも出来る

UNIXだったらパイプをポーリングすれば親の終了依頼とクライアントとの
通信を同時に待機できる

細かい使い方は自分で調べろ

240 ：デフォルトの名無しさん：01/11/21 14:30

>>239
>>235は強制的に終らせてなどと言ってるので通信は
ブロッキングでしたいのだと思われ。

241 ：デフォルトの名無しさん：01/11/21 14:51

>>224 うわ、頭の硬い奴。

242 ：デフォルトの名無しさん：01/11/21 14:59

他のスレッドに例外を発生させる方法って、あったっけ。

243 ：デフォルトの名無しさん：01/11/21 15:09

Javaなら。
スレッドを外から強制終了させよーとすると ThreadDeath 例外が走る。

244 ：デフォルトの名無しさん：01/11/21 15:15

すまん、舌足らずです。

Win32＆C++で、あるスレッドから別のスレッドに例外出せたら、
ちょっと悦なんですが。
ざっと調べた範囲ではなさそうだったんだけど、
見落としてるかもしれんので。

なんか情報あったらください。

245 ：　：01/11/21 16:42

Sub Macro1()
Dim i As Double
Dim iAnswer As Double

X = Worksheets(1).Cells(13, 2)
A = Worksheets(1).Cells(11, 7)

For i = X To A Step 0.0000001

iAnswer = i

Next

sAnswer = Str(iAnswer)

Worksheets(1).Cells(13, 8) = sAnswer

End Sub
-----------------------------------------
X=C10
A=IF(A13="",""ROUND(B13+E13+F13,6))
と、それぞれのセルには数式が入っています。
Aのセルは
sAnswerのセル(13, 8) に数値が入らないとAの答えが出ないから
「#DIV/0!」となってます

この状態で実行すると
For i = X To A Step 0.0000001
のとこで「型が一致しません」とエラーなります。
「#DIV/0!」だとダメなんでしょうか？

246 ：デフォルトの名無しさん：01/11/21 16:43

たとえば、そのほかのスレッドで頻繁にアクセスされるインスタンスなどを
ゼロクリアしてしまえば、そのスレッドがそのポインタをさわった瞬間に
Access Violation例外が発生するようにできますが。

やはりメッセージを受け取って、例外を送出するという方が無難でありましょうか。

247 ：デフォルトの名無しさん：01/11/21 16:58

>>243
イキナリThreadDeathのはなしより、普通は
「WAITスレッドにInterruptかけてInterruptedException」
のはなしが先でしょうに。

248 ：デフォルトの名無しさん：01/11/21 17:00

>>242
共有メモリのフラグを時々見に行って、フラグが
落ちていたら例外投げればいいじゃん。

249 ：名無しさん＠ＸＥｍａｃｓ：01/11/21 18:40

>>244
> ざっと調べた範囲ではなさそうだったんだけど、
> 見落としてるかもしれんので。

「Win32 マルチスレッドプログラミング」J. Beveridge, R. Wienerでは、
第五章「スレッドを制御する」に「何時間にもわたる調査の結果、
私は確信を持ってWin32 APIは別のスレッドに対して例外を送出するための
標準的な手段はサポートされてないと断言する事が出来る」だってさ。
// ここで言う「非標準の」はdebug APIで>>246など。

Compilerはかなり大変だよ、非同期に例外送出されると。
どの命令間でも例外が発生すると思って"exception safe"を維持するなんてさ。
けど、欲しい機能だけどね。pthreadのcancel pointみたいに限定局面でいいから。

250 ：242=244：01/11/21 23:47

むー、やはりそうか。情報ありがとうございます。＞みなさま

251 ：デフォルトの名無しさん：01/11/21 23:50

マルチスレッドとsignalって共存可能かにゃ？

252 ：デフォルトの名無しさん：01/11/26 01:24

>>251
する。と思うけど。

253 ：デフォルトの名無しさん：01/11/26 11:42

あと、何らかの手段で、そのスレッドのeipをとってきて、
スレッドが切り替わらないうちに、throw xxx;相当のコードに
書き換えてしまう、という手段がひょっとするとあるかもしれませんな。
まぁ、マルチプロセッサシステムでどうなるかは知りませんが。

254 ：デフォルトの名無しさん：01/11/26 12:35

排他制御ってどういう時に必要なのでしょうか？
銀行の預金の例、以外には無いのでしょうか？

255 ：デフォルトの名無しさん：01/11/26 12:49

銀行の預金の例ってなによ？

256 ：デフォルトの名無しさん：01/11/26 13:12

>>249
QueueUserAPC使えば近いこと出来そうな気がする
あくまで気がする程度だけど……無理かな？

257 ：デフォルトの名無しさん：01/11/26 13:38

>>254
複数のスレッドから１つの変数、ファイル、その他の資源を
アトミックな１つの操作（≒間に割り込みが入らない機械語１命令など）
ではすまない書き込み、あるいは更新
を行う必要がある個所ではすべて必要です。

258 ：デフォルトの名無しさん：01/11/26 15:55

>>254
自販機のボタンを同時押しされたときに
押した分だけ缶コーヒーが出てくる仕組みにしたくないときに
排他制御しろ。

259 ：253：01/11/26 16:57

debug API使って、別スレッドに例外を送出するやばめな方法。
http://www.geocities.com/ghanyan/throw_thread.html
x86 & Win32限定で使い道は全くないけど、まぁ、作ってみまたり。

260 ：結樹：01/11/26 17:11

まもなくアホでも理解出るようにと思って書かれたスレッドプログラミングの
本がでます。ご期待ください。
買ってくださったら感謝します。

261 ：デフォルトの名無しさん：01/11/26 17:53

>>258 ボタンの数だけスレッド(タスク？）が動いているのか！
スゴイ設計だな

262 ：デフォルトの名無しさん：01/11/26 18:00

>>260
あほが作ったマルチスレッドのプログラムって怖いな（ｗ

263 ：デフォルトの名無しさん：01/11/26 18:09

>>261
オブジェクト指向を始めて学んだときは
そういう設計をして楽しんだよ。
すぐに止めたけど

264 ：デフォルトの名無しさん：01/11/26 21:15

自販機のボタンを適当に置き換えて読め。

ビデオ鑑賞専用の個室とか、
トイレとか、
なんでもいいぞ。

265 ：結樹：01/11/26 22:59

>>262
レス感謝します。

266 ：結樹：01/11/26 23:01

>>265
すみません。慌てて書き込みました。

たしかにあほが作ったマルチスレッドプログラムは怖いですね。
時間ができたら、あほのためのマルチスレッドプログラミングの
ためのパターンランゲージを書いてみたいと思います。
良いアイデアがでました。感謝します。

267 ：DPの名無し：01/11/28 00:45

あほあほって云わんといてください。
本は買うと思うけど、あほが多数で実装しても困らない設計の進め方を
開発手法の観点から誰かと共著(don't treat）で、web公開してください。
(これぞ救済
あほじゃないやい。あほじゃないやい。DQNなんです。

268 ：デフォルトの名無しさん：01/11/28 01:26

そろそろ書籍名と出版社を明かしても良いのでは？

269 ：デフォルトの名無しさん：01/11/28 02:04

>>249
別スレッドの話はともかく、VC だと /EHa で非同期例外処理モデルになるね。

270 ：デフォルトの名無しさん：01/11/28 02:11

アホほどスレッドを使いたがるから困る
ちゃんと教育してほしい

271 ：デフォルトの名無しさん：01/11/28 02:14

効果的なとこに使えばよい。
なんだってそうだろ？

272 ：デフォルトの名無しさん：01/11/28 02:28

人のことあほあほいうやつはばか

273 ：デフォルトの名無しさん：01/11/28 02:38

>>270
ここで言っても仕方ない。それは「アホ」なヤツの上司に言え。

274 ：デフォルトの名無しさん：01/11/28 02:39

お前が教育しろ。>>270

275 ：デフォルトの名無しさん：01/11/28 11:02

TerminateThread()を実行した後にCloseHandle()でTerminateさせてハンドルを
クローズする必要は無いのでしょうか？
CloseHandle()で例外が出るのですが・・・

276 ：デフォルトの名無しさん：01/11/28 11:26

クローズしなくちゃだめです

277 ：デフォルトの名無しさん：01/11/28 14:02

>>275
例外が発生するのはおまえのプログラムが間違ってるからだ。
CloseHandleはしとけ。

TerminateThreadのヘルプはしっかり読んだか？

278 ：名無しさん＠Ｅｍａｃｓ：01/11/28 15:30

なんでそんなにけんか腰なんだ

279 ：270：01/11/28 19:02

教育したい相手が先輩だったりするんですが

280 ：デフォルトの名無しさん：01/11/28 22:37

>>279
ご愁傷様です

でも板違いなので、プログラマー板に逝ってね。↓このあたりに、ソースコードを編集して
貼り付けると良いかと。

この会社辞めようと思ったソースコード＃２
http://pc.2ch.net/test/read.cgi/prog/1001076034/

281 ：270：01/11/28 22:42

部分的に貼り付けても、分からないのがマルチスレッドの怖いところなんですけどもね。
グチになってますので去りますすみませんsage

282 ：デフォルトの名無しさん：01/11/28 23:58

要は「おれはマルチスレッドのテクニシャン」だということかね?

283 ：デフォルトの名無しさん：01/11/29 00:07

正直、posix threadは本でしか読んでない。
実務ではwin32上でしかマルチスレッドアプリ作ったことない。

でも（ﾟдﾟ）ｳﾏｰ

284 ：　：01/11/30 01:27

すいません、windowsで以下のような事できるんでしょうか。

スレッドを作って、そのスレッドの中で、オブジェクトを作って
そのハンドルをグローバルにセットして、親からそのハンドルで
メソッドを呼び出す事ってできるんでしょうか。

285 ：デフォルトの名無しさん：01/11/30 01:29

できるがそのハンドルって何なんだよ。
メソッドって何なんだよ。

所有権の管理と同期はきちっとやれよ。

286 ：デフォルトの名無しさん：01/11/30 02:37

>>285
おそらく、ＧＤＣやなんやのグラフィックオブジェクト
ハンドルのことではないか？
依然意味不明だが。

287 ：デフォルトの名無しさん：01/11/30 13:02

235です。
返事遅くなりましたが、>236-240さん、ありがとうです。
まだ自分の中では解決案は出ていませんが、今までの情報を元に
がんばってみたいと思います。

288 ：真希：01/11/30 13:35

電器機の営業をしてます。エクセルとかアクセスとか使って、顧客名と商品購入年月日を入力しておけば、
商品の買い替え時期（買った日からちょうど4年後）に、自動的に表示されるようなプログラム組むことって、できますか？
エクセルを少し習っただけの初心者なもので。。

289 ：デフォルトの名無しさん：01/11/30 14:00

>>288
それはマルチスレッドと、どのような関係がありますか？

290 ：デフォルトの名無しさん：01/11/30 14:09

>>288
大袈裟なソフト作らなくても
時々４年前の日付で検索かければいいだけじゃないの？
でスタートアップにショートカット入れとけば？

291 ：デフォルトの名無しさん：01/11/30 14:32

>>288
なんかかわいい♥

292 ：　：01/11/30 22:49

>>285
サーバーを作ってるんですが、とりあえず以下の様な事
ができないかなと思ってます。
初心者なもので、ほんとに出来るのかどうか、かなり
不安な状態です。

1.サーバーとクライアントのクラスを作っておく。
2.親がサーバーのインスタンスを作り、accept処理するメンバ関数を
　外部関数を通してスレッド呼び出しする。
3.クライアントからの要求があったら、accept処理するメンバ関数は
　クライアントの処理をするスレッドを呼び出す。
　その中でクライアントのインスタンスを作り（ハンドルをグローバル
　にセット）、recv処理をするメンバ関数でWhileで回る。
4.sendする場合は、親がセットされたハンドルを通して、クライアント
　のsend処理のメンバ関数を呼び出す。

親から、

293 ：あぁ：01/11/30 23:33

>>292
俺も今、チャットサーバ作ってるんで、知恵を出し合おう。
ていうかほぼ完成してるがね。

294 ：デフォルトの名無しさん：01/12/01 02:33

>>292
悪いことは言わない、スレッド使うのはやめたほうがいい。

295 ：293：01/12/01 03:07

>>294
ま、それは目的によるわな。何百件のクライアントを処理しなけりゃ
ならんようなサーバーではスレッドはキツイが、内輪で使うような
せいぜいクライアント数人のチャットサーバならスレッドでＯＫ。

296 ：デフォルトの名無しさん：01/12/01 08:40

たしかに学習目的ならまったくもってＯＫというか好例だね。

297 ：デフォルトの名無しさん：01/12/01 12:21

>>294
よければその理由を教えてください。

298 ：デフォルトの名無しさん：01/12/01 13:43

Linux 上でマルチスレッドを使ったプログラムを作ることになったのですが、
参考図書あるいは URL でおすすめがあったら教えてください。
英語のものでもかまいません。

299 ：shige：01/12/01 13:49

http://www.oreilly.co.jp/BOOK/pthreads/
表紙がキライだが

300 ：デフォルトの名無しさん：01/12/01 13:55

>>294
？？

301 ：デフォルトの名無しさん：01/12/01 13:59

>>298
これなんかどうでしょう?
自分がこれから買うつもりなだけなんだけども(w

＞POSIXスレッドプログラミングアスキーアジソンウェスレイシリーズ
＞―Ascii Addison Wesley programming series
＞David R.Butenhof (著), 油井尊 (翻訳), 宗方あゆむ (翻訳)

302 ：デフォルトの名無しさん：01/12/01 14:02

>>297
趣味なのか仕事なのかを教えてください

303 ：デフォルトの名無しさん：01/12/01 15:43

趣味だと動作不良起こしても良いと言う意味だろうか？？「

304 ：デフォルトの名無しさん：01/12/01 15:59

スレッドをオブジェクト化しようとしてスレッド関数を
メンバ関数にしようとしてもスタティックじゃないと、
できない。しかし抜け道が。

305 ：デフォルトの名無しさん：01/12/01 16:02

オブジェクトじゃないじゃん。

306 ：デフォルトの名無しさん：01/12/01 16:11

本買うようなことか？

307 ：297：01/12/01 17:08

>> 302
仕事です。(ちなみに、私は 292 ではありません)
以前、Windows2000上で >>292 と同じような処理をするプログラムを
作ったことがあったので。

308 ：デフォルトの名無しさん：01/12/01 19:49

>>299,>>301
Thanks, こんど都内に行ったら大きな本屋に寄って見てみます

309 ：デフォルトの名無しさん：01/12/09 13:15

>>259
9xだと非常にやばい。
NTだとクリティカルなコードはみんなカーネルモードにあるので
おおむね問題ないけど。

310 ：デフォルトの名無しさん：01/12/16 14:35

Winな話です。
メインスレッド＋ワーカースレッド複数個のときに、
それぞれのワーカースレッドからメインスレッドへ
SendMessageして特定の処理をしたいのですが、
あるワーカースレッドのSendMessageによって
メインスレッドのコールバック関数内に入っている
ときに、別のワーカースレッドがSendMessageを
送ってきたとすると、コールバック関数内の
コードが並行して走ることになるのでしょうか。
つまり、SendMessageに応答するコールバック関数内の
コードで、グローバル変数などの排他制御が必要なのか
ということです。

311 ：デフォルトの名無しさん：01/12/16 15:30

他スレッドからのSendMessageは、
自スレッドからのPostMessage同様、一旦メッセージキューに入る。

Advanced Windows読め。
http://www.ascii.co.jp/pb/msp/21292/21292.htm

312 ：デフォルトの名無しさん：02/01/17 22:10

Pthreadの説明したサイト誰か教えれ

313 ：U21：02/01/17 22:23

>>312
わたしはここで勉強しました。

http://www-6.ibm.com/jp/developerworks/linux/010119/j_l-posix3.html

３回物でこのページからたどって１回目からどうぞ。
わかりやすいと思います。

314 ：デフォルトの名無しさん：02/01/17 22:26

>>313
ありがとまんこ

315 ：デフォルトの名無しさん：02/02/05 23:24

あるスレッドが持つバッファに処理が終了して書いたデータを別の共有バッファにコピーし
その共有バッファが見えているもう一つのスレッドに、Notification　を送りたいのですが、
（その猛一つのスレッドはそのNotificationを受けるまで待っていて、受けたらそのデータ
を処理します。）　普通どう実装するものでしょうか？　スマートな方法とかありますか？

316 ：デフォルトの名無しさん：02/02/05 23:38

>>316
処理系くらい書けば？

317 ：デフォルトの名無しさん：02/02/07 16:17

下のようなプログラムをVC++6.0で書いていますが、
スレッド数が10ぐらいなら正常に終わるのですが、
スレッドを100とか1000にすると、なかなか終わりません。
原因は何でしょうか？

#define THREAD_MAX 10

volatile int stop[THREAD_MAX];

void thread_start(void *i) {
　　while(1) if ( stop[(int)i] == 1 ) break;
}

void test_thread(void)
{
　　int i;

　　for (i=0;i<THREAD_MAX;i++) {
　　　　_beginthread( thread_start, 0, (void *)i );
　　}

　　for (i=0;i<THREAD_MAX;i++) stop[i] = 1;
}

318 ：デフォルトの名無しさん：02/02/07 16:27

while(1)×1000 が CPU 食いまくっているので
for(...) stop[i]=1; の処理が回りにくいから。
ついでに 10 くらいだと thread_start が始まる前に
その stop フラグが立ってしまう可能性アリ。

#うそかもしれん。

319 ：デフォルトの名無しさん：02/02/07 16:41

>>318
ありがとうございます。
100個の時は100分の1のタイミングで切り替わるのではなく
重たいループに優先的にCPUが使われてしまう、と考えていいのでしょうか？

320 ：デフォルトの名無しさん：02/02/07 16:54

下のようにSleepを入れたら、スレッドが２つでも
終了しなくなりました。
マルチスレッドは難しい・・・。

for (i=0;i<THREAD_MAX;i++) {
　　Sleep(1000);
　　stop[i] = 1;
}

321 ：デフォルトの名無しさん：02/02/07 17:10

あー、なぜイベントを待たないのかね？

322 ：デフォルトの名無しさん：02/02/07 17:09

スレッドのwhileループの中に Sleep(0) でも入れてみ。

323 ：：02/02/07 18:46

>>320
ビジーループを使う理由は？
マルチスレッドの前にコンピュータの基礎を勉強してみれば？

324 ：デフォルトの名無しさん：02/02/09 02:15

Win32でスレッド使っうならAdvanced Windowsくらい読んだ方がいい。

325 ：デフォルトの名無しさん：02/02/09 02:20

専門書って高いよな……
これではずれだった日にはもう……

326 ：デフォルトの名無しさん：02/02/09 02:28

またブチキレですよ。

327 ：デフォルトの名無しさん：02/02/12 19:55

ＰＯＳＩＸスレッドをLinuxで勉強はじめたものなのですが、階層的な構造体のある一部分
だけＭＵＴＥＸでロックしたいのですが、その場合、pthread_mutex_t　変数を宣言する場所
は、例えば　struct B　の部分にのみロックをかけたい場合、以下のような風にすれば
よろしいのでしょうか？

struct A {
int a;
int b;
struct B bb:
} stA:
struct B {
pthread_mutex_t hoge:
int c;
int d;
} stB:

struct stA aa;

328 ：デフォルトの名無しさん：02/02/12 19:58

え？

329 ：デフォルトの名無しさん：02/02/12 19:59

３２７

スマソ、宣言が何か変でした、もいっかい…

struct stB {
pthread_mutex_t mutex:
int c:
int d:
}
struct stA{
int a:
int b:
struct stB bb:
}
struct stA aa:

330 ：デフォルトの名無しさん：02/02/12 22:13

>329
そのレベルなら好きにすれば？(´ー`)y-~~

331 ：名無しさん＠ＸＥｍａｃｓ：02/02/12 23:45

>>327
ロック変数は、ロックする対象と一対一に対応させて利用しさえすれば、
対象となる構造体の一部である必要はない。

struct T a;
pthread_mutex_t lock_for_a;

でもよい。

>>317,>>319-320
どうしてそうなるかは、Windowsの仕様ではなく、
Windowsの実装や動作環境に依存する話だから、
そんな物に依存しない様に同期を取りながらプログラムを記述せねばならない。

> 重たいループに優先的にCPUが使われてしまう、と考えていいのでしょうか？

そういうことはない。Busy loopがCPUを占有するだけ。

332 ：デフォルトの名無しさん：02/02/13 00:28

３２７

>>331

ご返答ありがとうございます。なるほど、ロック対象の対応をきちんとすれば
ロック変数の宣言はどこでもいいんですね。しかし一つ疑問が生じます。
pthread側はどこでロック対象のスコープ範囲を知る事ができるんでしょうか？

２つのスレッドＡとＢがあったとき、ＡがロックしたリソースをＢは解放されるまで
アクセスできないとしたときに、Ａがロックするものというのは何でもよいわけですよね？
構造体のインスタンスでも、一つの変数でも、構造体のリンクリストのずっと先の方でも…
ロックされる範囲をＢはどのようにわかるのでしょう？
それとも単にＡがソースコード中でロックとアンロックをした範囲内のデータは全て
ロックがかかるという事でしょうか？（つまりソースコード依存）
その間に構造体メンバーやグローバル変数が出てきたらそれらは全てロックがかかる
のでしょうか？

333 ：超先生@プログラム板：02/02/13 00:49

　 ∧＿∧
＜　｀ш´＞.｡oO（C言語のスコープは関係しない)
pthread_mutex_lockにて明示的にロックし、
pthread_mutex_unlockにて明示的にアンロックする。
保護がかかるのはあくまで*コード*であり、直接データが保護されるのではない。
データにアクセスするコードをmutexで保護することによって、
データへのアクセスがアトミックであることを保証することができるのだ。

334 ：デフォルトの名無しさん：02/02/13 00:51

331様、333様、どうもありがとうございました。

>>333
どうも勘違いして mutex lock　を理解していたようです。これで疑問が氷解しました。
ありがとうございました。m(__)m

335 ：デフォルトの名無しさん：02/02/13 00:52

>>334=327 でした。スマソ。

336 ：デフォルトの名無しさん：02/02/21 14:04

複数のスレッドのデバッグ情報を１つの画面に吐き出したいのですが、
「Win32マルチスレッドプログラミング」を読むと１つのデバイスコンテキストに
複数から描画するのはまずい、とあり、実際、プライマリスレッドが
作ったデバイスコンテキスト（hDC）に別スレッドからアクセスしても
フォント情報、背景色など、正しく情報を持って来れません。

やりたいことは、TRACE()の結果をIDEではなく、別Windowsに表示させる、
といった感じになのですが。

337 ：デフォルトの名無しさん：02/02/21 16:02

DebugViewでも使え
http://www.sysinternals.com/

338 ：デフォルトの名無しさん：02/02/22 11:53

>336
PostMessageでUIスレッドにメッセージ投げれ。
UIスレッドでは、そのメッセージをうけて、何か描画すれ

339 ：デフォルトの名無しさん：02/02/25 23:24

リエントラントでない rand() をマルチスレッドで使いたい場合みなさんどうしてますか？
あとpfintf()はリエントラント？　デバッグように出したりしてるんですが

340 ：デフォルトの名無しさん：02/02/26 00:11

randはだめでしょ。
どうしてもつかいたければ単体の乱数発行スレッドでメッセージ通信とか
すれば良いと思う。
printfはふつー再入可能じゃないのかなあ。まあ処理系に依存するよ。

341 ：デフォルトの名無しさん：02/02/26 00:27

rand()?
リエントラントでないならﾛｯｸすれば言いだけじゃないの?

342 ：デフォルトの名無しさん：02/02/26 00:37

339

>>340
別スレッド作るのはいやん

>>341
そうかロックしちゃえばいいのか

343 ：名無しだけれども：02/02/26 08:37

>>339
> あとprintf()はリエントラント？　デバッグように出したりしてるんですが

printf()はstdoutが共有リソースだから、
競合するようなら排他せざるを得ないでしょう。
printf()毎にライブラリがジャイアントロックする環境なら、
アプリ作成者がやる必要はないけど。
(ただしそのことをリエントラントとは呼ばない。MT-Safeではあるが)

fprintf()であれば、出力先が違う場合があるわけだから、
MT-Safeでかつリエントラントである実装が最近は多いはずだけど。

いずれにせよ、使っている環境のマニュアル読むこと。

func () { // MT-Safeではあるが、リエントラントとは言わない。
static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; // ジャイアント
pthread_mute_lock(&lock);
ほげほげ;
pthread_mute_unlock(&lock);
}

344 ：デフォルトの名無しさん：02/03/02 02:21

rand()の目的からいえば、別にlockしなくてもいいのでわ？
とかいってみる。ｌ

345 ：デフォルトの名無しさん：02/03/03 03:43

同じ乱数を再現する必要があるんじゃないの?
対戦テトリスとか。

346 ：デフォルトの名無しさん：02/03/16 22:34

sleep()で眠らせてるスレッドを強制的に起こす、またはそのスレッドを強制的に終了
させる良い方法ないですか？

347 ：名無しとは?：02/03/16 22:53

sleep()はやめて、pthred_mutex_lock()等で待て。

> そのスレッドを強制的に終了させる

極めて有害。

348 ：デフォルトの名無しさん：02/03/16 22:59

>>346-347
言語は合ってるのか？ｗ

349 ：デフォルトの名無しさん：02/03/16 23:07

>>347
一定時間止めておきたい場合はどうするの？
pthread_mutex_lockで待つのはいいとしても。

350 ：デフォルトの名無しさん：02/03/16 23:13

>>347
>>348
ptheadでもなんでもいいです。一般的にどうするのがいいのかなと…
やりたいのは一定時間眠らせておきたい（止めておきたい）んだけど
終了させたい時にはすぐにそのスレッドを終了させたい。
pthread_mutex_lock()の場合ロックハンドルを待つということは別途
一定時間を計るタイマーを持てと？タイマースレッドの実装って美ジ
ーループでしょ？やだな。

351 ：デフォルトの名無しさん：02/03/16 23:15

pthread_mutex_timedlockがあれば使う
無ければptherad_cond_timedwait

352 ：デフォルトの名無しさん：02/03/16 23:20

複数のmutexを同時に、あるいはどれか一つを取得するにはどうすればいいですか？

353 ：名無しとは?：02/03/16 23:32

>>352
1. pthread_cond_*()を使う
2. 通知する側が条件を調べて真の時に通知するようにする。(condと基本的に同じ)
3. 条件を調べて通知するthreadを作る。

354 ：デフォルトの名無しさん：02/03/22 17:25

あげ

355 ：デフォルトの名無しさん：02/04/13 23:58

UNIX板では答えが貰えなかったのでこっちで質問させて下さい。
FreeBSDの<pthread_np.h>に以下の関数が宣言されています。

int pthread_attr_setcreatesuspend_np __P((pthread_attr_t *));
int pthread_multi_np __P((void));
int pthread_resume_np __P((pthread_t));
int pthread_single_np __P((void));
int pthread_suspend_np __P((pthread_t));
int pthread_mutexattr_getkind_np __P((pthread_mutexattr_t));
int pthread_mutexattr_setkind_np __P((pthread_mutexattr_t *, int));
void pthread_set_name_np __P((pthread_t, const char *));
int pthread_switch_add_np __P((pthread_switch_routine_t));
int pthread_switch_delete_np __P((pthread_switch_routine_t));
int pthread_main_np __P((void));

これらの関数が何をするものなのか知っていたら教えて下さい。

356 ：デフォルトの名無しさん：02/04/14 02:04

FreeBSDならソースが読めるだろ。
後に_npついてるのはPOSIXに規定されてないと思う。

357 ：デフォルトの名無しさん：02/04/14 04:53

>>356
今、MSのFreeBSD向けCLIがLinuxでも動作するよう移植してるんですが、
PALのスレッドの辺りが上手く動かないからちと困ってます。
FreeBSDのmanpageにもでてこないし、検索してもまったく引っかからないし
やっぱりソース読むしかないかなぁ。。

358 ：名無しとは?：02/04/14 07:44

>>355
_npってのは、NOT POSIX。
だからpthread_np.hってのは、pthread関連ではあるが、
POSIXのpthread規格に入ってない関数等のheader。

// pthread_*_npって命名自体POSIXに規定されてるんじゃなかったかな。

359 ：デフォルトの名無しさん：02/04/14 08:31

>>358
_npはnot portableだと思ってたが。

360 ：デフォルトの名無しさん：02/04/15 12:39

2CPUが全く同時に同じところにアクセスしたらメモリはぶっ壊れますか

361 ：デフォルトの名無しさん：02/04/15 12:48

「まったく同時に同じところにアクセス」することを許すような
イカれたメモリコントローラの下では、
「まったく同時に同じところにアクセス」しなくとも、
メモリが煙を吐いて壊れるのは予想しうる事ではないでしょうか。

362 ：デフォルトの名無しさん：02/04/15 12:50

はい、ぶっ壊れます。

363 ：デフォルトの名無しさん：02/04/15 12:55

マジですか。ぶっ壊れますか。

364 ：デフォルトの名無しさん：02/04/15 12:56

それは大変だ。

365 ：デフォルトの名無しさん：02/04/15 12:56

Windowsでそれは有り得る？

366 ：デフォルトの名無しさん：02/04/15 13:01

みんなイジワルだな（ｗ

367 ：デフォルトの名無しさん：02/04/15 13:37

僕は意地悪されてたんですか。
>>361さんの書き込みで安心してたんですが、
これも意地悪なのですか。

368 ：デフォルトの名無しさん：02/04/15 21:37

普通は「まったく同時に」なんかアクセスされないようになってるから大丈夫。

369 ：デフォルトの名無しさん：02/04/16 00:33

安心しますた。

370 ：デフォルトの名無しさん：02/04/16 00:53

>>368
ウソはよくないぞ

371 ：デフォルトの名無しさん：02/04/16 00:59

不安です。

372 ：名無し人間：02/04/17 01:24

>>360は、
・"one writer, some readers"
・atomic
・cache coherent
って概念を勉強して自分で考えられる人間になるか、さもなくば、
自分の知りたい場合について詳しく説明しながら質問すること。

373 ：デフォルトの名無しさん：02/04/27 18:17

>>372
それらを勉強するのに適した書物等あれば、おせえてください

374 ：デフォルトの名無しさん：02/04/30 06:50

Apache2.0の正式リリースあげ！

375 ：デフォルトの名無しさん：02/04/30 11:36

マルチスレッドって、2穴同時挿入とかそういうイメージですか？

376 ：名無し人間：02/04/30 13:50

>>373
http://www.amazon.co.jp/exec/obidos/ASIN/482228056X/qid=1020141523/sr=1-1/ref=sr_1_2_1/250-4858489-2345044
とりあえずこれ。

後はタンネンバウムかなー。(良書とは言えないけど…)
http://www.amazon.co.jp/exec/obidos/ASIN/4894710471/qid=1020141710/sr=1-2/ref=sr_1_2_2/250-4858489-2345044
http://www.amazon.co.jp/exec/obidos/ASIN/4894712245/qid=1020141710/sr=1-4/ref=sr_1_2_4/250-4858489-2345044

377 ：デフォルトの名無しさん：02/04/30 16:05

これってどうですかね。Javaだけど一般的な知見もあると思う。

Javaスレッドプログラミング―並列オブジェクト指向プログラミングの設計原理
http://www.amazon.co.jp/exec/obidos/ASIN/4881359185/250-7376397-1451448

378 ：名無し人間：02/04/30 20:19

>>377
むっちゃ面白いよ。Javaやらない人も一読の価値あり。
>>372とは違って、ソフトウェア設計の話だけどね。

379 ：デフォルトの名無しさん：02/05/21 00:36

保守

380 ：デフォルトの名無しさん：02/05/24 19:30

質問です。

WinsockAPIを使おうと思うんですが、
これってWSA~ 以外の関数もMT-Safeなのですか？
MT-Safeのこともよくわかっていないので、もしよろしければ、
MT-Safeの定義を教えてください。

381 ：デフォルトの名無しさん：02/05/24 19:40

>>380
へー、WindowsでもMT-Safeっていう概念あるんだ。

SolarisでMT-Safeと言ったら、複数のスレッドから同時に呼び出しても
安全で、かつそれなりのconcurrencyで動くことを言う。

全体をロックしちゃって、1度に1つのスレッドしか入れないように
なってるやつは「Safe」と呼ぶ。

382 ：デフォルトの名無しさん：02/05/24 19:44

reentrantだったらMTSafeだろ

383 ：デフォルトの名無しさん：02/05/24 19:53

>>381の言ってることが変だと思う俺は素人ですか。

384 ：デフォルトの名無しさん：02/05/24 19:53

>>381-382
おお。ありがとうございます。
複数のスレッドで安全に動けばとりあえずMT-Safeということですよね？

過去ログでのWinsockのことと、CygwinのライブラリがMT-Safeでないとか、
Googleったら出てきたんで、不安になって聞いてみました。
(MSDN Libraryにも資料ないですし。)

ご教授ありがとうございます。

385 ：381：02/05/24 19:55

>>383
どこが変ですか？

386 ：デフォルトの名無しさん：02/05/24 19:58

>>381
>へー、WindowsでもMT-Safeっていう概念あるんだ。
ってとこじゃないですか？

おれは>>383じゃないですけど

387 ：381：02/05/24 20:03

>>386
Safe, Unsafe, MT-Safe, Async-Signal-Safe, Fork1-Safe
という分類はSolaris独自かと思ったんですが。
Winでも同じ定義かどうかは正直知りませんです。

388 ：デフォルトの名無しさん：02/05/24 20:07

少なくとも一般では（Solarisは死欄）MT SAFEは
複数のスレッドからどんなタイミングで呼び出されても
正常に動作することが保証されていることを指す

389 ：デフォルトの名無しさん：02/05/24 21:26

>かつそれなりのconcurrencyで動くことを言う。

そんな説明はmanにありません

390 ：名無し人間：02/05/25 02:39

>>381
http://msdn.microsoft.com/vfoxpro/downloads/updates.aspの
「Visual Studio 97 Service Pack」のところ読みなよ。

>>387
> Async-Signal-Safe, Fork1-Safe

それは今関係ないじゃん。

391 ：デフォルトの名無しさん：02/06/19 07:41

WIN32質問です。
ミューテクスと自動リセットイベントは何が違うのでしょうか。
先生方、どうかご教授を

392 ：デフォルトの名無しさん：02/06/19 08:04

mutexでの所有権を放棄するかわりに、EventをSetすることで
mutexと同じような動作をすることも、できないわけではない。
おそらく「自動リセットイベント」は、この際に疑似所有権を
譲渡されるタスクを１つに限定する(のでmutexと同じ)と
いうことだろう。

ただそうすると、mutexでは、それを所有しているタスクが
何らかの事情で死亡したときに、所有権がOSにより放棄される
(=他の生きているタスクに渡る)のに対し、Eventによる
疑似所有権は、(放棄が明示でしかありえないがゆえに)
放棄されず、きわめてまずい事態(所有権の喪失=永久待ち)を
引き起こす恐れがあるので、おすすめできない。
　　　　　　民名書房刊、「Auto Reset EventによりMutexは不要か」

393 ：デフォルトの名無しさん：02/06/19 08:24

先生、よくわかりました。
先生頭よすぎです！

394 ：デフォルトの名無しさん：02/06/19 09:12

民名書房かよ。

395 ：デフォルトの名無しさん：02/06/19 09:57

>>392
Windowsはスレッドが途中で氏んでもMutexを開放しない罠。

396 ：デフォルトの名無しさん：02/06/19 23:59

MSDOSでマルチスレッド（もどきでいいので）のプログラム作るにはどうしたら言いの？
だれかおしえてくらさい。

397 ：デフォルトの名無しさん：02/06/20 00:02

setjmp/longjmp

398 ：デフォルトの名無しさん：02/06/20 00:05

>>397
やはりそれしかないか・・・
ためしたんだけど、longjmpしたあとのreturnとかがうまくいかないです。

399 ：デフォルトの名無しさん：02/06/20 00:07

>>398
んじゃ、タイマ割り込みを使って自前でコンテキストスイッチ

400 ：デフォルトの名無しさん：02/06/20 00:20

スレッドってコンテクスト切り替えてるんですか？
その場合、切り替えのタイミングは大麻割り込み？？

401 ：デフォルトの名無しさん：02/06/20 01:56

>>400
大きく分けてユーザーランドのスレッドと、カーネルサポートのスレッドがある
その中でも実装によって異なるかもしれない(特にユーザーランド)
あとは本などで勉強してね(はぁと)

402 ：デフォルトの名無しさん：02/06/20 11:35

>>398
「うまくいかない」とだけ書かれてモナー。
とりあえずvolatileが必要に1000setjmp。

403 ：デフォルトの名無しさん：02/06/20 22:31

>>398
というか、setjmp/longjmpがどうやって動作しているのか理解してる?
コンテキストスイッチをsetjmp/longjmpでやるんなら、
まず自前で複数のスタックを確保して、jmp_bufを初期化してやんなきゃ。

とにかく最低限レジスタとスタックの保存と切替ができるようにしないとな。
本格的にやるならシグナルハンドラとかマスクとかも考えなきゃならんが。

404 ：398：02/06/20 23:46

>>403
一応生成されたアセンブラコード見てなんとなくは理解しますた。
だけど、コンテキストスイッチとかｻﾊﾟｰﾘです。。。

まだまだ勉強不足です。
出直してきます。

レスくれた人ありがとう

405 ：test：02/06/21 01:28

>>396
文章からすると小学生くらいだと思うが、答えてやろう。
MS-DOSのコマンドではプログラムは作れません。
Javaでも、VC++でも使えば幾らでもスレッドプログラミングできます。
GUIを出したくなければ、GUIを使わなければいいだけで無関係。

406 ：デフォルトの名無しさん：02/06/21 04:27

>>405
痴呆

407 ：デフォルトの名無しさん：02/06/23 05:37

>>395
ちゃんとWAIT_ABANDONEDで帰ってくるが。
クリティカルセクションなら解放しない。

408 ：フォルトの名無しさん：02/07/12 16:05

MSKK SQLのマーケが10年以上まえのトレンドを
気が狂ったように宣伝しています。
http://www.microsoft.com/japan/sql/choice/
並列処理ではマルチプロセスよりマルチスレッドの方がすべての面で
優れていると主張しています。で、最後にOracleよりMS SQLのほうが優れてる
と書いています。ヒャッヒャッヒャ。
マルチプロセス・マルチスレッド・マルチファイバ・ステートプログラミング、
どれが優れているのか・開発しやすいのか、語ってください。

409 ：デフォルトの名無しさん：02/07/12 16:19

マルチスレッドです。
ひたすらダーティーに。

410 ：デフォルトの名無しさん：02/07/12 17:03

>>408
そういう場合、Oracleより劣るところはどこか聞いてみると良い。

411 ：デフォルトの名無しさん：02/07/12 21:31

スレッドをバカにするとSolarisマンセー野郎に怒られますよ。

412 ：デフォルトの名無しさん：02/07/14 00:06

マルチスレッドは、デバッグ辛いのよね、正直。

413 ：デフォルトの名無しさん：02/07/14 00:28

設計が悪い

414 ：デフォルトの名無しさん：02/07/14 15:54

一つのオブジェクトに複数のスレッドが非同期にガシガシアクセスするという
設計のコードをデバグさせられそうになったのですが

逃げました

415 ：デフォルトの名無しさん：02/07/16 22:05

>>414 は、開発もできないしデバグと言う名のテスト要員にもなれませんでし
た。まあ，プロジェクトとしては助かったけどね。

416 ：デフォルトの名無しさん：02/07/26 02:59

保守

417 ：デフォルトの名無しさん：02/08/07 01:05

保守

418 ：デフォルトの名無しさん：02/08/09 00:55

ほしゅ

419 ：デフォルトの名無しさん：02/08/09 21:00

一周年記念カキコ

420 ：デフォルトの名無しさん：02/08/10 10:34

>>415
めでたくプロジェクトは潰れました

421 ：デフォルトの名無しさん：02/08/18 03:54

息の長いスレだね。
スレッドよりはコルーチンで作りたくなることが良くある。

422 ：デフォルトの名無しさん：02/08/18 12:55

win2kってworker thread/thread poolingがアプリから自由に使えるのな
IOCPの俺様実装とかできそうな感じ

423 ：デフォルトの名無しさん：02/08/30 01:32

よろしか上げ

424 ：おぱい：02/08/30 16:19

BCC5.5のコンパイラで32ビットのマルチスレッドアプリを作りたいんだけど、
Error: 外部シンボル '_main' が未解決（C:\BORLAND\BCC55\LIB\C0X32.OBJ が参照）
のエラーが出ます。

ソースは実験のためのシングルスレッドのスケルトンです。
bcc32 -W test.cpp
ではコンパイルできます。
DLLのソースなら
bcc32 -WD dll.cpp
でコンパイルできました。
スケルトンで
bcc32 -WM test.cpp
で、'_main' が未解決っていうことは、マルチスレッドならWinMain()
じゃなくて、別の関数名なんですか？

425 ：名無し人間：02/08/31 10:27

>>424
WinMainって一体なんなのか調べてみれ。mainとの違いを。

426 ：おぱい：02/08/31 12:58

'_main' が未解決っていうことは、main()が無い
って注意されていると思ったから、ハローワールドの
ソースで、bcc32 -WM hello.cpp
ってやったらコンソールのマルチスレッドがコンパイルできました。
32ビットコンソールなら
bcc32 -WC hello32.cpp
でできました。
BCC5.5では32ビットマルチスレッドのアプリは作れないんですか？

427 ：デフォルトの名無しさん：02/08/31 14:06

>>426
ボーランドに聞けよ...

428 ：おぱい：02/08/31 15:04

>>427には聞いてないよ。オマエ勘違い。藁。

429 ：おぱい：02/08/31 15:10

ここもレベル低いね。こんな簡単な質問に答えられないの？バッカみたい。
板ごと削除依頼しよっか？

430 ：デフォルトの名無しさん：02/08/31 15:15

>>429
必死だな。

431 ：デフォルトの名無しさん：02/08/31 15:55

簡単だったら何で質問するんだよ・・・

432 ：sage：02/08/31 16:09

433 ：K&R：02/08/31 16:17

おいおいレベルさがってるぞ～。
おばいくーん、こまるなー、ほんと、いるよねー、こーゆーひと

434 ：おぱい：02/08/31 16:30

429と430は同一人物。
BCC5.5を使ってない人には聞いてないいょぅ。

435 ：デフォルトの名無しさん：02/08/31 16:32

>>428ですでに信用がた落ちだからな・・・。

436 ：おぱい：02/08/31 16:37

だから、知らねー奴には聞いてないってば。
だいたいなー、ボーランドへの質問は18cm未満の人は
質問禁止なんだよ。知りたいならオマエが聞け。

437 ：デフォルトの名無しさん：02/08/31 16:40

＞18cm
ﾃｨﾑﾎﾟの長さですか？

438 ：デフォルトの名無しさん：02/08/31 17:00

おぱいだからアンダーとトップの差では？

439 ：おぱい：02/08/31 17:01

BCC5.5ではマルチスレッドでもシングルスレッドでも
コンパイル時のオプションは必要ないと分かりました。
bcc32 -W test.cpp
で32ビットGUIマルチスレッドもできました。

440 ：デフォルトの名無しさん：02/08/31 17:01

・・・ホームラン級のバカ？

441 ：おぱい：02/08/31 18:26

>>440
もう用は無い。うせろ。ﾜﾗﾜﾗ

442 ：デフォルトの名無しさん：02/08/31 21:15

基本がわかっていないので教えてください。
お願いします。(Win32環境です)

int G = 0;

void init_G(void)
{
　if(G == 0) {
　　if( バージョン判定式 ) G = 1;
　　else G = 2;
　}
}

上記のような場合でもやはり init_G()内の処理は
排他を考える必要があるでしょうか？

複数のスレッドが、あらかじめ init_G()を呼び出した後で
グローバル変数Gを読み取りのみに使います。(書き込みはしません)

また、バージョン判定式の部分はどのスレッドから
何回評価しても同じ結果を返し、かつ
この判定自体はスレッドセーフであるとします。

同時読み書きや同時書き込みが発生するが、
メモリ上のデータの整合性(一貫性)は保たれるので
排他の必要はない　と考えるのは間違いでしょうか。

443 ：デフォルトの名無しさん：02/08/31 21:34

>>442

考え方はあっている。

書いてあるプログラムも、「いったん判断式を評価したら、二度と評価しない」
となっているので、その点もよい。

444 ：デフォルトの名無しさん：02/08/31 21:37

(バージョン判定式)が
・何回行っても処理に問題はなく
・スレッドセーフであり
・常に同じ値を返す
のであれば、排他制御は必要無い(はず)。

一般には(上記のどれかを満たさないorコストがかかる場合)、Gをvolatileで宣言しておいて
void init_G()
{
　if (G == 0) {
　　lock();
　　if (G == 0) {
　　　if (...) {
　　　　G = 1;
　　　} else {
　　　　G = 2;
　　　}
　　　unlock();
　　}
　}
}
のように、初期化が必要になる可能性がある場合のみ、
ロックしてから再度判定する場合が多いと思う。

445 ：442：02/08/31 23:09

>>443,444
どうもありがとうございます。
基本的な考えは間違っていないようで、安心しました。

> 書いてあるプログラムも、「いったん判断式を評価したら、二度と評価しない」
> となっているので、その点もよい。

この理由がよくわかりませんでした。

私が if(G == 0) を付けたのは、
「判断式を評価する時間がもったいないから」というだけで
深い意味はなかったのですが、
他にも意味があるのでしょうか？
(判断式を何度評価しても動作に支障がない場合)

また、444 さんのコードの意味もよくわかりません。
void init_G()
{
　lock();
　if(G == 0) {
　　if (...) G = 1;
　　else G = 2;
　}
　unlock();
}
だけではまずいでしょうか？
lock() にかかる時間的コストを考慮？
lock() と unlock() が対になっていない点も疑問です。

446 ：444：02/09/01 00:34

ごめん。unlockの位置は{}とインデントをつけた時にミスった。

G==0を２度やっているのは、コストの問題。
本当にlockする必要があるのは最初だけで、それ以降は常にG!=0なのだから、
そのためだけに毎回lockするのは時間的に無駄だから。

例えば、Singletonなんかでインスタンスを初期化/取得する場合でも、
毎回実行する部分は出来るだけ軽くすべきであり、
最初以外はlockせずに値を取得出来るようにするため。

447 ：444：02/09/01 00:36

よく見たら、
>lock() にかかる時間的コストを考慮？
って書いてあった。その通りです。

448 ：デフォルトの名無しさん：02/09/01 01:12

>>444
そのコードだとGをvolatile宣言する必要はナシ。
そもそも、volatile宣言された変数へのアクセスって
意外とコスト高なんで注意すべし。

ちなみに>>444のアルゴリズムはDouble-Checked Lockingと
呼ばれているんだが、場合によってはうまく動かないことが
知られている。

具体的には、初期化の対象がatomicなアクセスが保証されている
primitive型の変数ではなく、緩いメモリモデルを採用している
プラットホーム上で動かした場合に、うまく動かない可能性がある。
緩いメモリモデルの例としてはJava memory modelとかがあるから
参考として以下の記事なんかを読んでおくのもいいよ。
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

449 ：444：02/09/01 01:36

どうもありがとう。
C/C++でも、volatileは必要無いのかな？
つまり、lockした後の再判定時に、コンパイラの最適化で
レジスタ等にキャッシュされた値を読んでしまうのを防ぐ必要があるかなと。

コスト的にも、C/C++なら、スタック以外の変数(の読み出し)にかかるコストは、
volatileでもそう変わらないと思ったし(読み出しが一回だけの場合)。
Javaなら、インスタンス変数をキャッシュする関係で差がつくのはわかるけど、
>>444は元々C/C++を想定していたから。
ただ、スタック上の変数の場合は、C/C++でもレジスタ割り付けの関係で差が付きそう。

あと、問題があることは知らなかった。
操作対象がatomicに操作できなくても、判定するためのフラグを用意すれば
一般的に解決できる問題なのかな？
とりあえず、リンク先読んでみる。

450 ：444：02/09/01 02:19

とりあえず、マルチプロセッサ環境において、
・コンストラクタが実行されて初期化されるまでの間
・(C/C++などのCPUキャッシュの同期が保証されていないものでの)メモリからの読み出し時
に問題があることはわかった。
その他はまだよく理解出来てないけど。

451 ：442：02/09/01 03:01

>>444
どうもありがとうございます。
おかげ様で大変よくわかりました。感謝感謝です。

今度は
>>448の
volatile宣言の必要がないというのがわかりません。

(444さんと同じ考えですが) volatileが無いと、
lock とunlock が通常の関数呼び出しとして実装されている
なら大丈夫としても、
仮にこれらがインライン展開される関数やマクロだった場合に、
・lockの直後のif文で G がメモリから再ロードされるかどうか
・更新後の Gの値がunlockの前でメモリに書き込まれるかどうか
が保証されないのでは？と思えます。

452 ：デフォルトの名無しさん：02/09/01 23:27

>>451
たとえば
mutex L;
int data;
として、スレッドAで
　lock(L);
　dataに代入; // …(1)
　unlock(L);
とした後、スレッドBで
　lock(L);
　dataの利用; // …(2)
　unlock(L);
ってしたとき、たとえvolatile宣言がなかったとしても
(2)において(1)の変更が見えないのはマズイ。
だから、
> 仮にこれらがインライン展開される関数やマクロだった場合に、
> ・lockの直後のif文で G がメモリから再ロードされるかどうか
> ・更新後の Gの値がunlockの前でメモリに書き込まれるかどうか
> が保証されない
なんてことがあったら、それはスレッドライブラリ側のバグ。
さらに、緩いメモリモデルをとっているアーキテクチャ上の
スレッドライブラリではlock, unlockの際に適切なメモリバリア命令を
実行していたりもする。

IA-32ではメモリ書き込み順やキャッシュ一貫性の保証があるんで
こういう話とはほとんど無縁だけど、pthreadの本とかでは
ここらへんが重要な話として載ってるよ。

453 ：名無し人間：02/09/01 23:57

>>452
> それはスレッドライブラリ側のバグ。
> さらに、緩いメモリモデルをとっているアーキテクチャ上の
> スレッドライブラリではlock, unlockの際に適切なメモリバリア命令を
> 実行していたりもする。

これは標準Cから逸脱している特定のシステムの話では?

454 ：デフォルトの名無しさん：02/09/02 00:07

>>453
当然逸脱してるけど、それを満たしていなかったらスレッドライブラリとして
使い物にならないって言う事じゃないの？
違ってたらｽﾏｿ

455 ：お役立ちサイトです。：02/09/02 00:18

究極の総合リンク集

http://home9.highway.ne.jp/cym10262/

456 ：名無し人間：02/09/02 00:32

>>454
>>452=458だと思てるんで、

> そのコードだとGをvolatile宣言する必要はナシ。

も含めてちと言い過ぎじゃないのかなと。

457 ：名無し人間：02/09/02 00:33

ｱｳ!

>>456
> >>452=458だと思てるんで、

< >>452=448だと思てるんで、

458 ：442：02/09/02 02:48

>>452
なんとなくわかりました。

たとえvolatileがなくても、lock/unlock の前後では必ず
メモリに反映されるような実装になっている(はずである)。
ということですね。

どうもありがとうございます。

459 ：452=448：02/09/03 21:32

>>456
ちょっと言い過ぎだったかもしれんが、
もしvolatile宣言が必要な処理系があったとしたら、
>>454の言うように「スレッドライブラリとして
使い物にならない」のは確か。

ポインタをvolatileと宣言しても、その指し示すデータは
volatileにならない(ちょうどconst宣言と同じ)から、
リストとか木とかちょっと大きめのデータ構造を
ロックしようとしたときにえらく面倒になってしまう。

460 ：デフォルトの名無しさん：02/09/03 22:17

つまりJavaのスレッドは使い物にならない、と。

461 ：デフォルトの名無しさん：02/09/03 23:26

>>460
誰もそんなこと言ってませんが?

462 ：デフォルトの名無しさん：02/09/05 00:35

pthreadのpthread_t（スレッドハンドラといういい方でいいのかな、WIN32だと
ハンドラというけど）型の変数や、pthread_cond_t型の変数を他のint型やchar型
のデータ構造体の中にいっしょに詰め込んでmallocして使ったらメモリー破壊
されまくり。ポインタにして分けてmallocしたらうまく動きますた。
何故何故？？

463 ：デフォルトの名無しさん：02/09/05 00:46

ハンドラとは言いません。ハンドルとはぜんぜん意味の違う言葉です。

464 ：デフォルトの名無しさん：02/09/05 01:19

つかぬ事をお聞きしますが、
マルチスレッド処理が必要なときって何？

465 ：名無しさん：02/09/05 01:55

>>462
> 何故何故？？

あなたの書いたプログラムにバグがあったから。

466 ：デフォルトの名無しさん：02/09/05 11:51

>>462
pthread_t
pthread_cond_t
だけ？
pthread_mutex_tがなきゃpthread_cond_tは意味を成しませんが。
どのような使い方をしているのか理解出来ないのですが・・・

467 ：デフォルトの名無しさん：02/09/05 21:38

>>464
必要な例：
いわゆるUNIXでは、fd(pipe/socket等)のポーリングと、sysv IPCの同期待ちと、
プロセス終了待ちと、pthreadの同期待ちを単一のスレッドで同時にはできない。
これは個別にスレッドを立てるしかない。

これ以外は再利用の都合じゃないでしょうか。
独自のループを持つ既存のモジュールを使いまわせるとか。

468 ：デフォルトの名無しさん：02/09/08 04:40

>>464
467の他に「CPUが複数あるマシンで速く計算するため」というのもあるな。

469 ：デフォルトの名無しさん：02/09/11 17:56

みなさん、↓はどう思います？
http://slashdot.jp/article.pl?sid=02/09/11/0131222&mode=nested

470 ：デフォルトの名無しさん：02/09/11 23:27

どうと言われても・・・

471 ：デフォルトの名無しさん：02/09/12 23:36

みなさん、↓はドゥー思います？
http://slashdot.jp/article.pl?sid=02/09/11/0131222&mode=nested

472 ：デフォルトの名無しさん：02/09/13 01:51

ｼﾗﾈｰﾖ

473 ：デフォルトの名無しさん：02/09/13 20:07

>>471
XEON買え、買えないなら諦めろ。
以上

474 ：デフォルトの名無しさん：02/09/14 00:44

そこでほとんど語られてんじゃん。

475 ：デフォルトの名無しさん：02/09/14 02:45

mutexを２種類使うケースってどんな場合があるのでしょうか？

476 ：デフォルトの名無しさん：02/09/14 02:56

>>475
質問の意味がわからん・・・

477 ：デフォルトの名無しさん：02/09/14 03:01

すみません。質問の仕方がまずかったかも
pthread_mutex_t 型のmutex変数を２つ以上使う場合ってどんな場合なのかなと
思いまして質問しました。

478 ：デフォルトの名無しさん：02/09/14 03:17

>>477
リソースが複数ある時とか。
セマフォと同じ用途。

479 ：デフォルトの名無しさん：02/09/14 03:28

マルチスレッドの入門書でも読んだ方が早いな

480 ：デフォルトの名無しさん：02/09/14 03:41

２つ以上必要な時はデッドロックに気をつけてな

481 ：デフォルトの名無しさん：02/09/14 12:05

>>480
確かにアタマが割れるようにイタイ！！！！
それはヘッドロック
てへ★ミ

482 ：デフォルトの名無しさん：02/09/14 19:29

>>467
> sysv IPCの同期待ちと、
> プロセス終了待ちと、pthreadの同期待ちを単一のスレッドで同時にはできない。
　スレッドを使わずとも、selectや、sigactionを使って同期を取れますが・・？

> これ以外は再利用の都合じゃないでしょうか。
> 独自のループを持つ既存のモジュールを使いまわせるとか。

　その糞モジュールが本当にスレッドでまともが使えるのか結構疑問にかんじますが。

>>486
> 467の他に「CPUが複数あるマシンで速く計算するため」というのもあるな。
　た、たとえばどんな？
　計算させたって、計算終わるまで結果待ちしてるヤシがいるのはずだけど、そいつは何してるの？
　画面描画？画面描画のための計算処理が重いのではないのか？

　「Windowsプログラミングでメッセージ処理とソケットの同期がスレッドでないと取れない」ぐらいしか漏れには思いつかない。

483 ：デフォルトの名無しさん：02/09/14 20:07

芳しいのが登場したからsage

484 ：デフォルトの名無しさん：02/09/16 23:45

gcc-2.96, glibc2.2上でMTなプログラムを書いています。そろそろプロファイラにかけたい
と思い、-pg付きでコンパイル・実行してみたのですが、gmon.outが出力されません。

プログラムは、^Cで止めるまで動き続けるものです。どうやらexit()がgmon.outを書き出す
らしいとわかったので、sigactionでSIGTERMをハンドルするようにしましたが、駄目でした。
なにか知恵をください。

485 ：484：02/09/16 23:50

>>484
SIGTERMはSIGINTの誤記です。ちなみに^Cではなく、
killall -INT program_name にしてます。

486 ：デフォルトの名無しさん：02/09/16 23:53

>>484

pthreadはよく知らんのだが、

#include <stdio.h>
#include <signal.h>
void h(int x){ exit(1);}
int main(void){ signal(SIGINT, h); while(1); return 0; }

漏れの環境では、single threadの上のは^Cでgmon.out出る。

487 ：484：02/09/17 00:33

>>486
似たようなコードでも、MTにしたとたん出ないです。

488 ：デフォルトの名無しさん：02/09/17 00:36

マルチスレッドとマルチプロセスってどう仕組みが違うんですか？
このバカに教えてください。

489 ：デフォルトの名無しさん：02/09/17 00:41

主に同じアドレス空間で動くかどうか

490 ：デフォルトの名無しさん：02/09/17 00:42

>>488
失せろバカ。

491 ：デフォルトの名無しさん：02/09/17 00:45

>>490
お前が消えろ

492 ：デフォルトの名無しさん：02/09/17 00:47

>>488
バカに理解させるのは疲れるのでいやです

493 ：488：02/09/17 00:58

>>489
アドレス空間とは･･･な、なんですか(鬱)

>>490
うっさい死ね

>>491
ありがとう

>>492
そんなこと言っちゃイヤンなので教えてください。

494 ：484：02/09/17 00:59

バカのお蔭で俺の質問が消えてく…

495 ：デフォルトの名無しさん：02/09/17 01:00

>>493
>>489が完璧。

496 ：デフォルトの名無しさん：02/09/17 01:07

アドレス空間。
あるアプリケーションが h0番地からhn番地までのメモリを使える時、
h0番地~hn番地までの範囲が、そのアプリケーションのアドレス空間。
プロセスp1とプロセスp2のアドレス空間は全く重ならないけど、
スレッドt1とスレッドt2のアドレス空間はぴったり一致する。

497 ：488：02/09/17 01:08

>>495
？
アドレス空間が完璧ってどういうことですか？

498 ：488：02/09/17 01:20

>>496
ありがとうございますm(．．)m
禿しく理解できました。
ついでにこれも聞いていいですか？
本を読んでWIn95はプリエンティブなマルチタスクでは無いとかなんとか
と書いてありました。
これはどういうことですか？

499 ：>>498：02/09/17 01:26

>498
今さらそんなことが書いてある本があるのか？
Win95はプリエンティブなマルチタスクですよ。

つーか、ム板民なら、そのくらい解れ。

500 ：デフォルトの名無しさん：02/09/17 01:37

preemptive　　
a(形容詞).　先制（攻撃）の；　先買権のある．　preemptively　ad(副詞).
投機実行があるという意味でしょう。
メモリに存在している複数のスレッド（一部は特定の仮想マシンを共有している）
間の投機実行が行われるという意味。実行中のスレッドを一時停止させ
別のスレッドを投機実行させる。non-preemptiveな場合はそういうことは
ない。ま、win3.1にはスレッドという概念すら無いに等しいが。

501 ：デフォルトの名無しさん：02/09/17 01:55

ハァ?

502 ：デフォルトの名無しさん：02/09/17 01:58

ひぃ？

503 ：デフォルトの名無しさん：02/09/17 03:58

いやん。

504 ：デフォルトの名無しさん：02/09/17 10:23

>>499
Win9xはプリエンティブなアプリとノンプリエンティブなアプリが
混在するから、不完全なプリエンティブマルチタスクと言われていたはず。

505 ：デフォルトの名無しさん：02/09/17 10:27

>>482
遅レスだが・・・

MsgWaitForMultipleObjectsとWSAEventSelect使えばメッセージ待ちながらソケット待てるよ。
Win32だとWSAEVENTは単なる手動リセットイベントだから。

Overlapped I/O使うならMsgWaitForMultipleObjectsExね。

506 ：名無しさん：02/09/17 14:20

>>494
つーか、Linuxなの?
だったらmain threadのpidにだけkillしてみれば?

507 ：名無しさん：02/09/17 14:23

>>504
あと、動的プライオリティ計算がせこいのも、
プリエンプティブスケジューラとしては貧弱でしたな。
ブーストと言われても…

508 ：デフォルトの名無しさん：02/09/17 23:24

>>506
Linuxデス

509 ：デフォルトの名無しさん：02/09/18 00:20

今まですっとWinなスレッドしか使ってなかったけど
linuxのpthreadってなんか使いにくくてしょうがない

510 ：デフォルトの名無しさん：02/09/18 06:05

>>509
自由にぼやいて貰って構わないんだけど、
「Winなスレッド」って生CThreadのこと?

511 ：デフォルトの名無しさん：02/09/18 10:17

>>509
http://pc.2ch.net/test/read.cgi/unix/1010933537/l50

512 ：デフォルトの名無しさん：02/09/18 16:35

>>511
キモイ関数が沢山ありそうだね

513 ：デフォルトの名無しさん：02/09/18 21:04

キモイの定義ができない人はム板にはいりません

514 ：デフォルトの名無しさん：02/09/19 23:26

あげ

515 ：純スレ：02/09/20 03:54

>>505
おお　そんなものがあるのですが、Win厨で失礼いたしましたぁ！_O_
しかし、ますますマルチスレッドプログラミングの必要性を見失いつつあり…。
最近はマルチスレッドプログラミングで苦悩している人を見ていると、とてもかわいそうなわけで…。

516 ：デフォルトの名無しさん：02/09/20 20:26

>>515
マルチスレッドプログラミングは、やればやるほど
スレッドを減らす方向に設計したくなるという面白い側面がありますね

517 ：デフォルトの名無しさん：02/09/22 12:03

_beginthreadex() が返すハンドルは CloseHandle() APIで閉じなければ
ならないという事なんですが、CloseHandle() を呼び出す位置は
_endthreadex() が (明示的もしくは暗黙的に) 呼ばれる前、呼ばれた後の
どちらでも構わないんでしょうか。

518 ：デフォルトの名無しさん：02/09/22 15:19

ハンドルは参照カウンタで管理されてるからどちらでもよい
不要だったら生成直後にcloseしてもよい

519 ：517：02/09/22 15:30

>>518
ありがとうございます、助かりました。

520 ：デフォルトの名無しさん：02/09/26 14:16

マルチスレッドのプログラムについて質問があります。
諸兄の知恵を貸してください。

現在、Solarisベースでpthreadを使用したプログラムを作成しています。
これはバックグランドで動作させ、デーモンとして使用するものです。

生成したスレッドの内部では、動的にメモリの獲得・解放を繰り返すのですが、
ps -el でSZの項目を監視すると、数値が増加しつづけてしまい、減少しません。
Purifyもかけてみましたが、リークはありませんでした。

原因を調べるためwebを検索したところ
ttp://www.ncad.co.jp/~komata/c-kouza28.htm
このようなサイトを見つけました。

>スレッド内で動的に多量のメモリを確保すると、プロセスサイズが大きくなり、戻らない
とあるのですが、これは「スレッド内部でメモリを確保しまくるとSZの値は減らない」と
解釈していいのでしょうか？

長文ですいません。

521 ：デフォルトの名無しさん：02/09/26 14:31

この前手伝ったプロジェクトは、Windowsのクライアントソフトに
がんがんスレッドを走らせていた。５つくらい。
あるひとりの優秀である（と言われている）人が設計したらしいんだけれど、
ソースコードにコメントが無いし、独自にCOMを実装してる（実装方法はCOMそっくり）
そのくせプラットフォームはWindows限定で、しかもSTLは使ってはいけなくて
……愚痴はやめておこう

さて本題ですが、個人的にはリソースが絡まないのにマルチスレッドにしないで欲しいんだけど、
一体何の理由があってマルチスレッドを利用したんだと思いますか？
部外者の俺が思うに、
・ある程度知識のあるプログラマが自分にしか理解出来ないコードを作ることで、支配基盤をはっきりさせたかった
・過去に作っていた自分のプログラムを再利用したかった（でもコードを見ると多分違う）
・クライアントマシンにマルチプロセッサの時代が来る事を見越していた（これもコードを見ていると多分違う）
・パズルが好きだった。

マルチスレッドをよく使う方々、他になんか理由があれば教えてください。

522 ：デフォルトの名無しさん：02/09/26 14:42

何をするクライアントか書いてないから判断しようがない

windowsということで、STLを使ってDLLとデータをやりとりすると、
ランタイムの関係でメモリ周りで問題が出る場合がある

あんたが差してるリソースの定義が曖昧だ、
CPUリソースもリソースであるという考え方も出来る

要するにお前は死ねって事だ。

523 ：デフォルトの名無しさん：02/09/26 15:01

相談室ということで、質問をさせてください。

今、Windowsで_beginthread()関数を利用して、経験のため無意味にスレッドを走らせています。
しかし、処理があまりにも遅くなるのでちょっと不可解に感じていました。
そこで、ループの先頭にSleep(1);を付け加えたところ、急にスムーズに動きました。
何が原因でこのような現象が起こるのでしょうか？

524 ：デフォルトの名無しさん：02/09/26 15:07

一つのプロセス内にあるスレッドがどれも必死で
CPUを使おうとしているから、
OSがその競合を解消しなければならなくなる。
↓
Windowsはそんなに賢くない。
↓
遅い。

Sleep(1);を加えると、OSはアイドルタイムをスレッドに割り振る処理しか
しなくてよいので、負担が減って早くなる。と、てきとうなことを言ってみるテスト。

525 ：デフォルトの名無しさん：02/09/26 15:11

>>521
我儘と傲慢が文中に溢れてるね。
久々に見たｲﾀｰｲ作文だな。

突っ込みどころ満載だけど、一部。
コメントが無いってのは、
　「自分じゃ理解出来ないから説明しる」
STL は使ってはいけなくてってのは
　「自分は STL バリバリだから使え」
スレッド使う意味があるのかってのは
　「私はスレッドについては無知なので
　　是非使うのを止めて頂きたい」
って事か?

自分より出来る人を陥れる事に夢中になりやがって。
そいつのレベルを越える事に精進しな。

526 ：デフォルトの名無しさん：02/09/26 15:41

>>525
その通りかも。精進します。

しかしコメントが無いのはマジで困りました。本当に理解できないのです。
WaitForMultipleObjectsが、一体どのリソースを待っているのか確認するのは大変でした。

STL使っては行けない理由はサイズが大きくなるからだそうです。
MFCのCArrayとかを使いなさいと言われました。

スレッドを使う意味があるのかってのは、本当に解らなかったからです。
どんなクライアントかを簡単に言うと、ドロップされたjpeg画像を読み込んで、
それを横一列にサムネイルで表示するだけのプログラムでした（その当時は）。
その後、ネットから画像を読み込む様に対応させる方向にするのかもしれないですね。
その意味では予めマルチスレッドで実装させる必要があるのかもしれません。

ちょっと厨房な質問スマソでした＞ALL

527 ：デフォルトの名無しさん：02/09/26 15:56

サムネイル作成は結構重い処理だから
bgで作成してないとアプリが固まったようになってしまう

って事じゃないの？

528 ：525：02/09/26 16:18

>>526
をっ、マジだったのね。きつぃ言動ｽﾏｿ。

使う、使わないの理由聞いてんじゃん。
2ちゃんで聞くより、本人(SE)が暇そうな時に
もっと直接聞いたほうが間違いないと思うけどな。
まぁ、いろんな意見を集めた方がいいけど...

529 ：デフォルトの名無しさん：02/09/26 16:20

>>527
それだけでもないみたいです。というのも、別にサムネイルを作るところを
別スレッドにしているわけではなくて、ただサムネイルを表示する
GUIの部分の、独自メッセージのやりとりをしている部分がマルチスレッドでした。

例えば、何もないダイアログを作り、そこにボタン、スクロールバー、
エディットボックス、などなどを追加していきます（プログラムで）。
で、一斉にそれらがマルチスレッドで処理を始めるという具合です。
それぞれ普通にプロシージャを使ってWindows任せで処理すればいいと思うんですが…。

>>523
多分、他のスレッドと同期を取って計算しているんだと思うけれど、その同期の取り方が
適当なグローバル変数などを使ってやってるのではないでしょうか？？
例えばスレッドＡでflag=1にすると、スレッドＢの処理がはじまる、というような場合、
スレッドＢでは、while(flag!=1);　みたいに待機しているんだと思います。
その時に、一度flag!=1を確認すれば、すぐに別スレッドに処理を移すべきなのだけれど、
もちろんOSではそんなことはわからず、ある一定の決められた期間スレッドＢでは
ひたすらflag!=1を評価し続けます。この時間はまるまる無駄です。

そういうタイミングでSleep(0)を入れてやると、すぐに別スレッドに処理が移るので、
効率的にCPUを使うことが出来る、という現象だと思います。
（この場合、Sleepは1でなくて0で問題ないはずです）
どうでしょうか？

530 ：デフォルトの名無しさん：02/09/26 17:41

>>521
そいつはやる気のある天才だな。
自分よがりとはいえ、そこまでの技術を「たかが」仕事で使ってしまう辺り、
自分の仕事に自信があり、その会社でも正当な評価を受けてる証拠だろう。
そういうコードはめったに見れないから、素直に見習ったほうが良いぞ。
ここで聞かずに、その天才に聞けよ。(なんで本人に聞かない？)

531 ：デフォルトの名無しさん：02/09/26 21:41

>>529
> そういうタイミングでSleep(0)を入れてやると、すぐに別スレッドに処理が移るので、
> 効率的にCPUを使うことが出来る、という現象だと思います。
> （この場合、Sleepは1でなくて0で問題ないはずです）

「マルチスレッド同期」あたりで、一回グクッてみることをお勧めする。

532 ：デフォルトの名無しさん：02/09/26 21:58

>>523
EventかFiberを覚えよう

533 ：デフォルトの名無しさん：02/09/26 22:00

>>531
間違ってないんじゃね？
Sleepせずにビジーループで変数待機してると
割り当てCPU時間全部使うまでCPU解放しないわけだし。

534 ：デフォルトの名無しさん：02/09/26 22:06

同期については
Windowsにはウィンドウメッセージという機構があるんだから
ぜひともそれを使っていただきたいものです

下手に俺様キューを作るよりよっぽどマシです...

535 ：デフォルトの名無しさん：02/09/26 22:15

>>533
> 間違ってないんじゃね？

別に間違っているとは言っていない。そもそも...

>> 例えばスレッドＡでflag=1にすると、スレッドＢの処理がはじまる、

に対して...

>> スレッドＢでは、while(flag!=1);　みたいに待機しているんだと思います。

なんてことは普通しない。素直に、Event ととか使えば、スレッド B は待ってる間全然 CPU を使わない。

536 ：デフォルトの名無しさん：02/09/26 22:29

>>534
該当スレッドにウインドウが無い可能性もあるだろ
あと、WindowsのメッセージはHWND指定がついてくるのが気持ち悪い。
素直にイベントに汁

537 ：デフォルトの名無しさん：02/09/26 22:30

>>536
ウィンドウがなくてもメッセージキューとして使えることを
知らないアフォが多すぎ

538 ：デフォルトの名無しさん：02/09/26 22:36

>>537
勿論知ってますが。
GetMessageでHWNDの指定を強制させるのが嫌すぎというだけです。
非同期ソケットとか、トレイアイコンにも言えることですが。

539 ：デフォルトの名無しさん：02/09/26 22:37

強制ってのは何か違うな、、、
MSGにhwndが入っているんだから、それで良いじゃないかってだけです。

540 ：デフォルトの名無しさん：02/09/26 22:46

GetMessageのHWNDにNULL指定できることを知らないのか？
ヘルプもロクに読めないとは・・・

541 ：デフォルトの名無しさん：02/09/26 22:49

送り側スレッドがPostThreadMessageで送って、
受け側スレッドがGetMessageで受けるんでしょ。

それでメッセージキューが実現できるという話だと思うんだが
何をゴネてるの？

542 ：デフォルトの名無しさん：02/09/26 23:11

>>540
勿論知ってるっつーの
GetMessageにHWNDがあるのが気に入らないだけ

543 ：デフォルトの名無しさん：02/09/26 23:32

（　´_ゝ｀）ﾌｰﾝ

544 ：ゲイﾁｭ：02/09/27 00:22

>>542
気に入らないならWindows使うな( ﾟДﾟ)ｺﾞﾙｧ

545 ：デフォルトの名無しさん：02/09/27 00:47

>>529
> それぞれ普通にプロシージャを使ってWindows任せで処理すればいいと思うんですが…。

何故いいと思うのか根拠書かないと。

GUIスレッドを自前で持つなんて、
Look&Feelのレスポンスが重要な局面ではよくやることだよ。
何も不思議なことはやってない。(少なくとも提示されている条件内では)

それよりも君の>>521の姿勢がずっと疑問。
AFCのスレッドモデルについてちゃんと理解してるの?

546 ：デフォルトの名無しさん：02/09/27 00:53

>>545

MainThread:

547 ：デフォルトの名無しさん：02/09/27 00:54

>>545

>>521
＞さて本題ですが、個人的にはリソースが絡まないのにマルチスレッドにしないで欲しいんだけど、
これ見る限り素人だし相手にしても無駄だよぅ

548 ：デフォルトの名無しさん：02/09/27 00:56

送信ミス、スマソ

>>545
MainThread: ダイアログを作る -> サブスレッド起動
Sub1: ボタンのメッセージを処理
Sub2: スクロールバーのメッセージを処理
Sub3: エディットボックスのメッセージを処理

って事じゃないの？

>で、一斉にそれらがマルチスレッドで処理を始めるという具合です。
こう書いてあるし

549 ：デフォルトの名無しさん：02/09/27 01:00

>>548
読み間違いに一票。
単に521が仕事できないだけだろ。

550 ：デフォルトの名無しさん：02/09/27 01:09

>>529
＞スレッドＢでは、while(flag!=1);　みたいに待機しているんだと思います。
こんな事考えてる様なやつだしね（ｗ

551 ：デフォルトの名無しさん：02/09/27 01:11

>>550
それは523があまりにも初心者だから、そう推測したんじゃないのか？
と、擁護してみる。

552 ：デフォルトの名無しさん：02/09/27 01:14

>>520
> >スレッド内で動的に多量のメモリを確保すると、プロセスサイズが大きくなり、戻らない

ここの、

> とあるのですが、これは「スレッド内部でメモリを確保しまくると
> SZの値は減らない」と解釈していいのでしょうか？

「スレッド内で」はあってもなくても同じ。(古典的UNIXとC(++)では)
単純ヒープモデルのメモリ管理は一度でかくなったら元に戻らない。
brk(2)を小さくするために呼び出すことはない。
// 「スレッド内で」と書いてあるのは、プロセスからの類推で、
// スレッドが終了したら、利用していたメモリも
// 解放されると誤解する人がいるからでしょう。

理由は、malloc(3)したメモリオブジェクトの位置を変えられないので、
羽抜け状態になるからです。emacsでは可変長オブジェクト用ヒープの
コンパクションをして、巨大化を防いでいます。
(それでもいったん大きくなるとそのまま)

話せば非常に長くなるので、
http://www.saiensu.co.jp/books-htm/ISBN4-7819-0303-7.htm
の「動的な記憶割り付け」を。さらに進むには、
http://www.google.com/search?q=garbage%20collection%20site%3Aamazon.co.jp&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8
でも読んでください。英語読めるなら、これも。
http://www.amazon.co.jp/exec/obidos/ASIN/0471941484/qid=1033055505/br=1-1/ref=br_lf_fb_1/249-2956017-1293960
"w3m"のweb pageとドキュメントも参考になるかも。

ちなみにthread関係ないから、
この話題続けるならUNIXプログラミングスレに。

553 ：デフォルトの名無しさん：02/09/27 04:42

マルチスレッドってどういう時に使うの？

554 ：デフォルトの名無しさん：02/09/27 06:32

>>553
エロゲーやりながらオナニーしたいときとかだね。君の場合。

555 ：デフォルトの名無しさん：02/09/27 07:56

>>554
マ板へどうぞ

556 ：デフォルトの名無しさん：02/09/27 09:19

>>542

　嗚呼、無能なヤシは困る…

　505をお読みになったか？

557 ：デフォルトの名無しさん：02/09/27 09:25

どうでもいいがWaitFor～じゃメッセージ待機出来ても取得できないぞ

558 ：デフォルトの名無しさん：02/09/27 10:26

>>557
WaitFor～じゃメッセージ待機できない。
できるのはMsgWaitFor～だよ。

それでもメッセージの取得はできないが、メッセージが届いている事を
前提にできるから、GetMessageでブロックせずに取り出せる。

559 ：デフォルトの名無しさん：02/09/27 10:59

>>558
GetMessageが気に入らないんじゃなくてHWNDが嫌いなんだから、
PeekMessageも当然ダメだろ。

560 ：HWND：02/09/27 12:06

すみません、僕のことで揉めるのは止めて貰えないでしょうか?
僕だって困ってるんです。隠居して、田舎暮ししたい…

561 ：デフォルトの名無しさん：02/09/28 16:58

NULL指定してても気に食わないとかいう理由で
だめとか言ってるんだから単なる言いがかりだろ

562 ：542 じゃねーけど：02/09/28 20:23

>>561
> NULL指定してても気に食わないとかいう理由で
> だめとか言ってるんだから単なる言いがかりだろ

言いがかりって...、Windows マンセー野郎様ですか ?

メッセージキューは本来もっと一般的なものだから、基本的には HWND なんてものがいらない素のバージョンの API があって、ウィンドに対するメッセージは、これをラップして使えばいいと思う。
でも、Windows では大多数がウィンドに対するメッセージだから、HWND 付きのメッセージ機構のをウィンド無しでも使えるようにしたという実装も理解できなくは無い。
俺はそう言う実装は嫌いだけど、それ以外の利点が大きいから Windows を使う。ただそれだけじゃないの ?

563 ：デフォルトの名無しさん：02/09/28 20:58

気に入る気に入らないの問題だったらどうでもいいです

564 ：デフォルトの名無しさん：02/09/28 23:33

>>562
使うもなにも、用意されてる選択肢がそれしかないんですけど。

565 ：デフォルトの名無しさん：02/09/28 23:36

ハァ？自前でメッセージキュー作れますが？

566 ：552：02/09/28 23:37

>>552
がーん、コピペ失敗した…

> さらに進むには、
> http://www.google.com/search?q=garbage%20collection%20site%3Aamazon.co.jp&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8
> でも読んでください。

これです。
省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集
http://www.amazon.co.jp/exec/obidos/tg/detail/-/books/4894714086/glance/249-2956017-1293960
省メモリシステムに限らず、メモリ管理全般に有用です。

567 ：デフォルトの名無しさん：02/09/28 23:39

>>565
わざわざ気に入らないからって、スレッド対応のメッセージキュー作るの？

568 ：デフォルトの名無しさん：02/09/28 23:46

>同期については
>Windowsにはウィンドウメッセージという機構があるんだから
>ぜひともそれを使っていただきたいものです
>下手に俺様キューを作るよりよっぽどマシです...
そういう風に作ってしまった場合、
ログオンプロンプト(パスワード入力画面)のまま、
ATコマンドやRPCでプログラムを起動したらどうなるの?
これがWindowsのプログラムのヤナ部分。

569 ：デフォルトの名無しさん：02/09/28 23:49

なんの話？

570 ：デフォルトの名無しさん：02/09/28 23:51

>>568
GUIスレッドと
ATコマンドやRPC発行スレッドを
別にすりゃいいんでないの？

571 ：デフォルトの名無しさん：02/09/28 23:55

>>569
たとえばTVのタイマー録画のソフトを作った場合、
パスワードを入れた状態でユーザーが外出したり
することになるでしょ。
デスクトップを開いていない状態でウインドウハンドル
を操作するAPIを実行するとそこで停止するかエラーになるでしょ。

572 ：デフォルトの名無しさん：02/09/28 23:58

いまいちよくわからんのだが。
もしかして、関わらない方が良い？

573 ：デフォルトの名無しさん：02/09/28 23:59

571はエラーになることを確かめたの？

574 ：デフォルトの名無しさん：02/09/29 00:04

>>同期については
>>Windowsにはウィンドウメッセージという機構があるんだから
>>ぜひともそれを使っていただきたいものです
>>下手に俺様キューを作るよりよっぽどマシです...
>そういう風に作ってしまった場合、

>デスクトップを開いていない状態でウインドウハンドル
>を操作するAPIを実行するとそこで

HWNDにNULLを入れるからウィンドウハンドルは操作しませんよ？

575 ：デフォルトの名無しさん：02/09/29 00:04

ウインドウシステムと依存関係のあるモジュールを
使ったプログラムは、ログアウトした状態では
使えなくなる欠点があるだろ。
だから、夜間にログアウトした状態で
OLEを使ってエクセルのシートを集計したりできないわけ。
端末の上でしか動かないという制約のあるモジュールは
なんだかな。

576 ：デフォルトの名無しさん：02/09/29 00:06

>>571はエラーになることを確かめたの？
NT上で確かめたよ。
サービスの作り方で、停止するかエラーかが決まる。

577 ：デフォルトの名無しさん：02/09/29 00:06

>>575
ちょっと飛躍するけど、user32.dllを使ったAPIやつが駄目って事？

578 ：デフォルトの名無しさん：02/09/29 00:07

s/APIやつ/API/

579 ：デフォルトの名無しさん：02/09/29 00:08

575-576
それってMessageBoxとかを出すときの話では？

元はメッセージキューをWindowMessageで代用するという話だったのに、
いつのまにすり替わりましたか？

>>572
あんたするどい

580 ：デフォルトの名無しさん：02/09/29 00:08

>>565
> ハァ？自前でメッセージキュー作れますが？

普通作れるだろ ?
>>567 の言うように普通は、「作らない」けどな。

>>572
俺もそう思う。

581 ：デフォルトの名無しさん：02/09/29 00:17

つかサービス用にデスクトップが割り当てられるだろ。
使ったこともないくせに想像でモノを書いてるUNIXプログラマ様ですか?
とか>>572の警告を無視して釣られてみる。

582 ：デフォルトの名無しさん：02/09/29 00:21

>>562
HWNDにNULLを指定すればHWNDなんてものはいらないだろ。
お前はほんとにGetMessageの引数にNULLがあるせいで困ってるのかと
小一時間問い詰めたい
単にMSの設計はセンスが悪いって言いたいだけちゃうんかと。

583 ：間違えた：02/09/29 00:21

s/NULLがあるせいで/HWNDがあるせいで/;

584 ：デフォルトの名無しさん：02/09/29 00:27

>>582
> 単にMSの設計はセンスが悪いって言いたいだけちゃうんかと。

ただそれだけだけど ? (つーか、>>562 は普通そうとしか取れないと思うが。)

誰も困ってるなんて書いてない (除く >>560) んですが、妄想ですか ?

585 ：デフォルトの名無しさん：02/09/29 00:32

>>584=562=話の流れを理解してないやつ?
つーかね。きみ文章ヘタ。

586 ：デフォルトの名無しさん：02/09/29 00:43

>>585
で、あんたは何言いたいの ?

587 ：デフォルトの名無しさん：02/09/29 01:02

>つかサービス用にデスクトップが割り当てられるだろ。
システムからダイアログを唐突に出されたら止まるから却下。

588 ：デフォルトの名無しさん：02/09/29 01:05

デスクトップが唐突に出てきた背景の説明キボンヌ

589 ：デフォルトの名無しさん：02/09/29 01:07

依存関係を作るって事に対する疑問符だな。

590 ：デフォルトの名無しさん：02/09/29 01:17

>でも、Windows では大多数がウィンドに対するメッセージだから、
>HWND 付きのメッセージ機構のをウィンド無しでも使えるようにした
これのソースキボンヌ。
この挙動は保証されているのかな。

591 ：デフォルトの名無しさん：02/09/29 01:22

>>588-590
Win32APIスレに移動だな
もはやマルチスレッドとは関係ない

592 ：デフォルトの名無しさん：02/09/29 01:22

URL忘れスマソ
http://pc3.2ch.net/test/read.cgi/tech/1032548635/l50

593 ：デフォルトの名無しさん：02/09/29 01:27

すんません、話の流れとそれるかも知れませんが
WindowsでGetMessage等を呼ばずにシステム互換のメッセージキューを作る方法教えてくれませんか？

594 ：デフォルトの名無しさん：02/09/29 01:30

Windows限定だったらwin32apiスレで聞けば？

595 ：デフォルトの名無しさん：02/09/29 01:32

>>593
MUTEXをロック
受信側は共有メモリにFIFOバッファを作る。
ポーリング時だけ開放

送信側は送信時にMUTEXをロックしようとする
→相手がポーリグするまでブロックされる。

双方向にする場合は双方でFIFOを持ったうえで
さらにデッドロックしないようにプロトコルを明確化する。

596 ：デフォルトの名無しさん：02/09/29 03:14

>>595
> MUTEXをロック
> ポーリング時だけ開放
> 送信側は送信時にMUTEXをロックしようとする
> →相手がポーリグするまでブロックされる。

それって一個しかデータが入らないから、キューじゃねーじゃん。

普通は、ポーリングする瞬間だけロックして、キューが空だったら何らかの同期機構で待つ。
送信側も書き込む瞬間だけロックして、キューが満杯だったら待つ様に作る。

(普通のキューと同じだと思うが...。)

597 ：デフォルトの名無しさん：02/09/29 03:29

入門書にでも書いてありそうなことをここでやるの？

598 ：デフォルトの名無しさん：02/09/29 03:33

>それって一個しかデータが入らないから、キューじゃねーじゃん。
FIFOだからキューだろうが。普通はリングバッファにするわけだ。
>普通は、ポーリングする瞬間だけロックして、
>キューが空だったら何らかの同期機構で待つ。
つまり、開けて待機することがポーリングなわけだ。
双方向だとデッドロックとかめんどくせぇ問題が起きるから
なるべくサーバー・クライアント型にして、
サービス側リクエストがくるまでずーーと待機というデザインだな。
オレの場合。

599 ：デフォルトの名無しさん：02/09/29 03:36

>>597
つまらないと思うなら無視すればいいだろ
いちいち突っ込むなボケ

600 ：デフォルトの名無しさん：02/09/29 03:57

>>599
無知がほざくなボケ

601 ：デフォルトの名無しさん：02/09/29 04:21

>システム互換のメッセージキューを作る方法教えてくれませんか？
だれもこれを満たしてない

602 ：デフォルトの名無しさん：02/09/29 04:21

>>600
童貞が吠えるなハゲ

603 ：デフォルトの名無しさん：02/09/29 04:22

>>597-602
お前らまとめて逝ってよし

604 ：デフォルトの名無しさん：02/09/29 04:23

>>603
禿
・
同

605 ：デフォルトの名無しさん：02/09/29 04:26

>>602
低学歴はすっこんでろ

606 ：デフォルトの名無しさん：02/09/29 04:30

>>604
プッ
ずれてるよ
バーカ

607 ：929：02/09/29 05:00

>>598
> なるべくサーバー・クライアント型にして、
> サービス側リクエストがくるまでずーーと待機というデザインだな。

それは、キューとは言わん。

608 ：デフォルトの名無しさん：02/09/29 05:03

>>605
マジで言ってるのか？
氏ねよボケ

609 ：デフォルトの名無しさん：02/09/29 05:05

>>608
低学歴なお前が死ね

610 ：デフォルトの名無しさん：02/09/29 05:39

>>609
まずお前が死に方の見本を見せろ

611 ：デフォルトの名無しさん：02/09/29 05:42

まあまあ、落ち着け。お前等のおかけで、このスレが「哲学者の食卓」みたいになってるよ。
二人とも、ちょっと Sleep(100) ぐらいしてこいや。

612 ：デフォルトの名無しさん：02/09/29 05:50

>>611
まずお前が氏ね

613 ：デフォルトの名無しさん：02/09/29 06:13

すみなれたーわがやにー　はなのかほりをそーえてー
　やさしくーそだったー　じゅもくかほりもいーれてー
このまちでーいちばんー　すてきでくらしたーいー
　りふぉーむーしようよー　しんーにほんーはーうすー

614 ：デフォルトの名無しさん：02/09/29 06:27

環境はLinux + pthreadで、

/* pthread_createに渡す関数 */
void* thread_func(void* arg)
{
　　int* sd = arg;　　/* sd: ソケットディスクリプタ */
　　char c;

　　while (1) {
　　　　int result = read(sd, &c, 1);

　　　　if (result == 1) {
　　　　　　fputc(c, stdout);
　　　　} else if (result == 0) {
　　　　　　usleep(WAIT_MSEC);
　　　　　　continue;
　　　　} else {
　　　　　　perror("read on thread_func");
　　　　　　pthread_exit(NULL);
　　　　}
　　}
}

…としています。ソケットにデータが流れてきた時にreadするように書きたいのですが、
usleepを使う以外の方法はありますか？

615 ：デフォルトの名無しさん：02/09/29 06:41

>>614なんでselect使わんの？

616 ：デフォルトの名無しさん：02/09/29 07:03

(´-`).｡ｏＯ(select知らないんだろうなあ)

617 ：デフォルトの名無しさん：02/09/29 07:14

CreateThreadで作られたスレッドには、lpParameterで指定した情報しか
わたすことができないんですか？
初心者な質問でｽﾏｿ。

618 ：デフォルトの名無しさん：02/09/29 07:16

つーか自分でやってみりゃいいじゃん

619 ：617：02/09/29 07:31

自分でやってみてどうしようもなくなりました。
２つ以上のパラメータを渡したかったらどうするんですか？

620 ：デフォルトの名無しさん：02/09/29 07:59

>>619
パラメータのリストを渡す

621 ：デフォルトの名無しさん：02/09/29 08:55

>>617
パラメーター構造体を定義して、mallocして
そのポインタを渡すというのが常套手段ッス～

622 ：デフォルトの名無しさん：02/09/29 09:14

そしてスレッドを使わないプログラムに回帰するのであった・・・
というネタが繰り返されるスレはここですか？

623 ：初心者：02/09/29 16:43

初心者が質問してごめんなさい。
今、エディタにプログラム書いて、コマンドプロンプトでコンパイルしてみたいな
ことしているんですが、マルチスレッドってこんな環境で使えるの？VCのような
開発環境でないとダメ？

624 ：デフォルトの名無しさん：02/09/29 18:01

>>623
開発環境は関係ない。
というか関係があるのかどうか自分で判断できるように努力しる。

625 ：デフォルトの名無しさん：02/09/29 18:12

>>624 ﾈﾀにﾏｼﾞﾚｽすんなﾊｹﾞ

626 ：デフォルトの名無しさん：02/09/29 18:17

>>614,615
select知りませんですた(´･ω･`)ｼｮﾎﾞｰﾝ。ありがとう。

627 ：デフォルトの名無しさん：02/09/29 23:16

プログラムは、理論を学習するのと、理論なくしてプログラミングを実践するのとどっちが重要ですか。

628 ：デフォルトの名無しさん：02/09/29 23:18

スレ違いに気づかないようなバカは何をやっても無駄
http://pc3.2ch.net/test/read.cgi/tech/1006617496/l50

629 ：デフォルトの名無しさん：02/09/29 23:24

>>628
ほざくな

630 ：デフォルトの名無しさん：02/09/30 01:51

>>627
マジレスするとどっちも重要。
実践して壁に当たってから理論せれ。
壁に当たらんと、理論のありがたさがわからん。

631 ：デフォルトの名無しさん：02/09/30 09:59

>>630
http://pc3.2ch.net/test/read.cgi/tech/1033317659/l50

632 ：デフォルトの名無しさん：02/10/01 02:23

質問。

スレッドをいくつか作成して、
メインスレッドが各スレッドにPostThreadMessage、
サブスレッドはGetMessageでそれを捌く。

これを数万～数十万オーダー繰り返すとたま～にGetMessageがデッドロック起こす現象に悩まされたことがあるんだけど、
他にそんな人いる？

すっごいシンプル（１００行未満）なテストプログラムでも起こったんで、何か原因があるとは思うんだけど見当つかなかった。

633 ：デフォルトの名無しさん：02/10/01 02:47

>>632
再現するソースは？

634 ：デフォルトの名無しさん：02/10/01 10:14

>>617,619
構造体のポインタか、クラスのポインタわたせば？

635 ：デフォルトの名無しさん：02/10/01 10:16

>>634
s/構造体のポインタ/構造体のインスタンスのポインタ/
s/クラスのポインタ/クラスのインスタンスのポインタ/

636 ：デフォルトの名無しさん：02/10/01 12:23

>>632
while(GetMessage(&msg,NULL,0,0))
とかやってないよね

637 ：デフォルトの名無しさん：02/10/01 12:49

>>636
いけないの？
どこのサンプルでも-1をチェックしてないようだけど

638 ：636：02/10/01 13:43

>>637
確かに、大抵のサンプルはそうなってるけど、チェックした方がいいよ。
↓を見てね。
http://www.microsoft.com/japan/msdn/library/ja/jpwinui/html/_win32_getmessage.asp

639 ：632：02/10/01 14:22

ども。
数年前の話だったので久しぶりにソースおこして確認してみました。

その結果、PostThreadMessageで10001個目のメッセージをPostするとエラーが返っていたことが判明。
GetMessageはエラーを返さず、GetLastErrorも0を返していたけれど
単純にメッセージキューのオーバフローが原因だと思われます。

前回はエラーチェックが甘かったのかな。
結局自前でスレッド間メッセージキューを実装してしまいました。
まぁその経験がその後の仕事で活かされた（pthread使う仕事があった）ので
自分的には結果オーライでしたが。

640 ：636：02/10/01 14:29

>>639
原因は判明したみたいだから、参考までに･･･
http://www.microsoft.com/japan/msdn/library/ja/jpwinui/html/_win32_postthreadmessage.asp

641 ：デフォルトの名無しさん：02/10/01 14:30

-1が失敗であって、-2が成功とも言えるからチェックがめんどくさいな

642 ：デフォルトの名無しさん：02/10/01 17:09

>>640
かつてのSetMessageQueueSizeの説明には
ポストできるメッセージの数に上限はなくなったとか書いてたのに
なんかインチキくさいな

643 ：デフォルトの名無しさん：02/10/01 17:58

つか回数制限を知らないヴァカがいることが驚き。

644 ：デフォルトの名無しさん：02/10/01 18:31

>>642
×SetMessageQueueSize
○SetMessageQueue
上限がなくなったとは書いてない。
必要に応じて拡張されるようになったと書いてある。
Win2Kにおける既定の拡張限界が10,000ということ。

645 ：デフォルトの名無しさん：02/10/01 20:55

メッセージを取り出さないで10000個Postしたって事？
普通にアプリケーション組んでれば、10000個以上のメッセージの送受信普通だが。

646 ：デフォルトの名無しさん：02/10/01 21:25

10000個も滞留するのが普通なのか・・・

647 ：デフォルトの名無しさん：02/10/02 09:42

>>644
10,000個以上の必要には応じてくれないんですか?
やっぱ強引というかMSに好意的過ぎる解釈だと思う。
古いPostMessageのヘルプにはこんな制限書いてなかったし

648 ：デフォルトの名無しさん：02/10/02 13:36

>>647
>10,000個以上の必要には応じてくれないんですか?
ヴァカ発見(ﾌﾟ

649 ：デフォルトの名無しさん：02/10/02 14:38

>>647
何事にも制限はある。
どうしても、
10000個以上のメッセージを溜める糞ソフトを書きたければ、
レジストリを修正しろと書いてるだろ。
あと、この10,000という数はWin2kにおける数値だから、
Win2kが出る前の古いヘルプに書いてあるわけがないと思われ。

650 ：デフォルトの名無しさん：02/10/02 14:40

>>649
Win2000以前には制限がなかったのに
突然制限つけてドキュメントのほうまで変えるのが納得できない。
今まで95/98/NT4で動いていたプログラムが
動かなくなるってことでしょ。

651 ：デフォルトの名無しさん：02/10/02 18:06

>>650
試してみた？
手元にあったWin98マシンで試すと、
1000くらいが限度みたい。
95/NT4は手元にないので試せないけど。

652 ：デフォルトの名無しさん：02/10/02 18:54

>>647
おまえみたいなアフォがｺﾞﾙｧして来てウザいから追加されたんだろ。

653 ：デフォルトの名無しさん：02/10/02 19:37

ここは強引なAPIの変更、それによるソフトウェアの構造の変更を
強いられることをありがたがるオメデタイMS信者しか居ないようですね。

こういった変更が無いことが保証されている環境は存在しないのでしょうか。
もうこれ以上馬鹿を見るのはごめんです。

654 ：デフォルトの名無しさん：02/10/02 20:32

致命的なバグがあっても改善されない環境を
望んでいる変人がいるすれはここですか？

655 ：デフォルトは上限無しさん：02/10/03 01:24

WinのAPIが安定しないことは確かだが、
>>644,649はどうみても妥当。セマンティクスは厳密になり、
しかも上限は変更可能になっている、ということで言い掛かりだと思う。

と>>653に釣られてみる。

656 ：デフォルトの名無しさん：02/10/03 01:36

win界隈はドキュメントされてるだけマシっつう話もアルヨ・・・

657 ：デフォルトの名無しさん：02/10/03 02:45

LinuxやFreeBSDなら「ソースを使え、ルーク」なのだろうが
Appleとかどうするんだろ

658 ：デフォルトは上限無しさん：02/10/03 04:43

>>657
とりあえずDarwinのソースでまあなんとか。
え? Mac OS < 9ですか? およびでない? 失礼しました～。

659 ：デフォルトの名無しさん：02/10/04 11:43

>>657
＞「ソースを使え、ルーク」なのだろうが
ﾜﾗﾀ

660 ：653：02/10/04 21:29

windows上C言語でプログラミングしてて、マルチスレッドを使おうとしてます。

CreateThread()を使おうと思ってるのですが、作成したスレッドには一つしか引数を渡せないのでしょうか？
複数の引数を渡したいのですが･･･

661 ：660：02/10/04 21:30

653と名のってますが間違いですｗ

662 ：デフォルトの名無しさん：02/10/04 22:23

クイックソートをマルチスレッドで書いたら速いので教えてください。

663 ：デフォルトの名無しさん：02/10/04 22:53

>>660
>>617 >>619
バカばっか・・・

664 ：デフォルトの名無しさん：02/10/04 22:56

>>662
並列アルゴリズムソート
でgoogleしてみよう！

つかCPU数が2以上じゃないと多分効果ないと思う

665 ：660：02/10/04 23:53

>>663
thanks

666 ：デフォルトの名無しさん：02/10/05 00:32

Windowsでプログラムしてマルチスレッドを使おうとしています。

BeginThreadを使おうと思っているのですが、作成したスレッドには1つしか引数を渡せないのでしょうか？
複数の引数を渡したいのですが・・・

667 ：デフォルトの名無しさん：02/10/05 00:43

これは何かの陰毛なのか？

668 ：デフォルトの名無しさん：02/10/05 00:43

>>666
お前、ちょっとは頭使え

669 ：660：02/10/05 01:26

>>668
お前、ちょっとは頭使え

670 ：デフォルトの名無しさん：02/10/05 01:37

構造体、、

671 ：デフォルトの名無しさん：02/10/05 02:53

ネタは放置

672 ：デフォルトの名無しさん：02/10/05 03:41

>>442
大昔の話をいまさらだけど、素朴な疑問。

それらのスレッドが動き出す前に１回init_Gを呼んでおく
（そして各スレッドでは呼ばない）
ってわけにはいかないんですか？
まあそういかないから質問してたんでしょうけど。

673 ：デフォルトの名無しさん：02/10/05 08:32

>>672
・init_G()が呼ばれるかどうかは事前には判らない
・init_G()の呼び出しは少なからず何らかの常駐リソースを食う
　(DLLのロードやメモリアロケート等)

という前提ならああしたくなるでしょうね。

674 ：デフォルトの名無しさん：02/10/13 03:06

なんとなく浮上

675 ：デフォルトの名無しさん：02/10/13 08:22

あるスレッドに文字配列を渡そうとして以下のようにやってみて、受け取り成功したのはいいのですが
このPostThreadMessageしたときに渡したローカル変数bufは、自動的に解放されますか？（受け取りで何かする必要あり？）

//送信側
char buf[]="ゴルァ";
PostThreadMessage(idThread, WM_USER+10000, (WPARAM)buf, 0);

//受信側
GetMessage(&msg, NULL, 0, 0);

676 ：デフォルトの名無しさん：02/10/13 09:32

自動変数なら、関数から抜けたときに開放される。
そういうう変数をPost～で渡すのは、不確実性の元。
渡してはいけない。

677 ：675の上司：02/10/13 15:52

>>675
バカ野郎！そんなコード納品したらクビにするぞ！
二度とするなよ。いいな？

どうしてもやりたきゃ、こうしろ。
PostThreadMessage(idThread, WM_USER+10000, (WPARAM)"ゴルァ", (LPARAM)">>675の上司より");

678 ：デフォルトの名無しさん：02/10/14 04:11

Javaでタイムアウト付きのwait()した時に、notify()されたのか、
タイムアウトしたのかを判断する方法知ってる人いる？

つーか、何でタイムアウト付きwait()の戻り値がvoidなの？

679 ：C ◆dq2PerGLN. ：02/10/14 04:31

CFileのMFCにあるファイルを開くダイアログはC＃だとどのクラスでどのメソッドにあたるのですか？

680 ：デフォルトの名無しさん：02/10/14 04:40

>>679
誤爆？

681 ：デフォルトの名無しさん：02/10/14 09:46

>>678
区別する方法は知らない。

> 何で
区別する必要がないから、じゃない？

682 ：678：02/10/14 16:42

>>681
あ、やっぱ出来ないのね。つーか、何で区別する必要ないの？
notify()されたかタイムアウトしたかって完全に意味違うぞ。

pthread_cond_timedwait()はタイムアウトしたらETIMEDOUT返す。
WaitForSingleObject()もWAIT_TIMEOUT返す。
普通はこんなもんだと思うんだが。

やっぱJavaって変な仕様多いな・・・(^^;

683 ：681：02/10/14 16:57

そりゃ変だよ。最初はthread.stop()なんていう糞仕様があったぐらいだし。
複数オブジェクトに対しor条件でwaitできれば少しはマシだったのに。
ああでも最近のJavaがどうなってるかは知らないよ。
1.4なんてぜんぜん見てない。

> 完全に意味違うぞ。

意味は違うけど、その後の処理は
　*ほとんどの場合においてほとんど同じ*
という罠。

solarisのman pageのcond_timedwait()の使用例でも、抜けた後、
「やっぱり処理する必要があるかチェック」してたりする。

俺のトリアタマでは、複数のワーカースレッドが単一のリクエストキューを
待つ、という使い道しか思いつかないや。

684 ：名無しさん＠ＸＥｍａｃｓ：02/10/14 18:53

pthread_cond_timedwait()がtimeoutを決めてから、
pthread_cond_signal()が発行された時、
timedwait()を行った側でsignal状態の後始末をする必要があるかどうか?

ある: 返り値で区別出来てもraceは残る。→何らかの方法で解決。
ない: しかしどちらかは知る必要はある: 返り値で教えろや、(ﾟДﾟ)ｺﾞﾙｧ!
　　　どちらでもいい: (´-`).｡ｏＯ(返り値何のためにあるのだろう)

最初の場合は、排他しながら調べるしかないね…

685 ：681：02/10/14 19:21

>>683
確かに普通の場合はほとんど同じことが多いかもしれない。

ちょっとWin32のEventみたいなの作ってて、wait()系のメソッドを
包んだ待機メソッド(タイムアウト付きも)実装するのに不便だな、と。

686 ：デフォルトの名無しさん：02/10/15 00:00

セマフォをOSでなくソフトで実現する方法ってありますか？

687 ：デフォルトの名無しさん：02/10/15 00:13

>>686
メッセージとか共有メモリを使って
代替の機能は作れると思うけど。

意味は、ないわな。

688 ：デフォルトは上限無しさん：02/10/15 14:40

>>686
セマフォは本来ソフトウェアだけで実装できるものだが、
タスク切り替えをしなければいけない/した方が効率がいい都合上、
カーネルスレッドなシステムではカーネルに実装されていること多い。

自分で実装する場合、タスク切り替えをどうするか考えないといけない。
M:Nスレッドが実装されているシステムだと、CPUを明け渡すAPIがあると思う。
Linux, *BSD, Solaris, NGPTのソースが参考になる。

UNIX System V IPCのセマフォのように、
processが死んだ時のundoを実装しているような高機能なものを作ろうとすると、
やはりカーネルの世話にならざるを得ない。

689 ：デフォルトの名無しさん：02/10/16 00:34

>>687-688
ありが㌧。

690 ：デフォルトの名無しさん：02/10/22 04:26

Redhat8, gcc-3.2, glibc-2.2.93 でコード書いているんですが、acceptが妙な
戻りで帰ったとおもったら直後、突然SIGKILLされてしまいます。

[pid 8618] <... accept resumed> 0x4185fa6c, [0]) = ? ERESTARTSYS (To be restarted)
[pid 8617] <... select resumed> ) = ? ERESTARTNOHAND (To be restarted)
[pid 8618] +++ killed by SIGKILL +++
+++ killed by SIGKILL +++

これの原因、何かわかりませんか・・?　tcpのポートをbindしてacceptしている
だけなんですが。。

691 ：デフォルトは上限無しさん：02/10/22 16:29

>>690
> 妙な戻り

signalによるsystem callの中断って分かりますか?
/usr/include/linux/sched.hのマクロなんかでは積極的に使ってますね。

pid 8617の方は、signalによるsystem callの中断があり、
system callをrestartしようとしたら、
指定されていたfile handleがなくなっていた、というエラーです。

glibcはpopen(3)以外ではSIGKILLを出さないみたいだけど…
状況がよく分からないので、こんなところですね。

692 ：デフォルトの名無しさん：02/10/23 05:49

WIN32ですが、クラス内でスレッド作るってどうやるんでしょう？

693 ：デフォルトの名無しさん：02/10/23 12:13

>>692
クラスの中で_beginthreadしてください
としか言えない

Javaみたいにクラスまるまるスレッド化とかは無理よ？

694 ：デフォルトの名無しさん：02/10/23 12:27

>>693
startメソッド呼んだらrunメソッドが新しいスレッドで
走るクラスくらい簡単に作れると思うけど

695 ：誤爆くさいので貼ってみる：02/10/24 15:51

446 名前：デフォルトの名無しさん投稿日：02/10/24 11:12
//以下では駄目なのですがどのようにすれば良いのでしょうか？
//ThreadReceptionはクラス内で定義したいのですが・・

class ThreadClass {
public:
void ThreadHead();
void ThreadReception(void*);
private:

};
void ThreadClass ::ThreadHead (){

_beginthread(ThreadReception,0,0);

return;
}
void ThreadClass ::ThreadReception(void*){
return;
}

696 ：誤爆くさいので貼ってみる：02/10/24 15:52

>>695
_beginthreadex

697 ：デフォルトの名無しさん：02/10/24 15:52

あ、名前欄戻し忘れた

698 ：デフォルトの名無しさん：02/10/24 15:56

ごめん_beginthreadでもできた。
コンパイルして確認とってないから間違ってるかもしれないけど
そのへんは適宜脳内補完してくれ
class ThreadClass {
public:
void ThreadHead();
void ThreadReception(void);
private:
static void ThreadClass::RealThreadReception(void* tc);
};
void ThreadClass ::ThreadHead (){

_beginthread(RealThreadReception,0,(void *)this);

return;
}
void ThreadClass ::ThreadReception(void){
return;
}
static void ThreadClass::RealThreadReception(void* tc){
return ((ThreadClass *)tc)->ThreadReception();
}

699 ：デフォルトの名無しさん：02/10/24 23:48

度々すいません・・。
'_beginthread' : 1 番目の引数を 'void (void *)' から 'void (__cdecl *)(void *)' に変換できません
っていわれるんですが・・。

700 ：デフォルトの名無しさん：02/10/25 06:42

>>699
いわれたまんまだろ
そのぐらい自分でどうにかしろ

701 ：699：02/10/25 07:14

すいません、勘違いでした。
無事コンパイル通りました、ありがとうございました。m(__)m

702 ：デフォルトの名無しさん：02/10/26 21:58

Cの通信アプリで、
printfを削除すると挙動が変わってしまうのですが、
そんなときどうすればよいのでしょうか？

703 ：デフォルトの名無しさん：02/10/26 22:02

>>702
挙動が変わる原因がタイミングによるものでないなら、原因は 99% 以上君のプログラムのミスだから、ソースコードレビューを死ぬほどやりなさい。

704 ：デフォルトの名無しさん：02/10/26 23:08

printf入れると、スレッドのプライオリティが下がる
ような挙動なんです。

705 ：デフォルトの名無しさん：02/10/26 23:11

はぁ？

706 ：デフォルトの名無しさん：02/10/26 23:29

WaitForSingleObjectに渡すハンドルをもとに、
別スレッドからこのスレッドを破棄したいのですが、
可能でしょうか？

707 ：デフォルトの名無しさん：02/10/26 23:48

>706
Win32の話ね。
WaitForSingleObjectに渡すハンドルってスレッドハンドルのことなら
TerminateThreadに渡せばスレッド終了できるけど…。
独自プロトコル作ってイベントやメッセージで通信するのがお勧めだよ。

708 ：デフォルトの名無しさん：02/10/27 00:48

>>704
>>705 じゃないけど、確かに「ハァ ?」だよ。
単に、「スレッドのプライオリティが下がるような挙動」じゃわけわからんよ。
具体的に何がどうなるのか書いてみ。

709 ：デフォルトの名無しさん：02/10/27 00:54

アーカイブってどういう意味？
馬鹿ですいません　教えてくださひ

710 ：デフォルトの名無しさん：02/10/27 00:55

>>707

ありが㌧。
私の考え方がマズかったです。
SetEventを使用した独自プロトコルでうまくいきました。

711 ：デフォルトの名無しさん：02/10/27 00:56

>>709
***すれ立てるまでもない質問はここで　第24刷***
http://pc3.2ch.net/test/read.cgi/tech/1035354069/l50

712 ：デフォルトの名無しさん：02/10/27 00:58

>>709
辞書ぐらい買うか、ググルぐらいしたら ?

http://www.yamagata.tao.go.jp/HTML/keyword.htm

つーか、激しくスレ違いだよ。

713 ：デフォルトの名無しさん：02/10/27 01:01

＞７１１
サンキュ
＞７１２
すまん

714 ：695：02/10/27 12:43

クラス内にスレッドを作成して、そのクラスを配列で複数定義して
処理を同時進行でするようなプログラムを作ったんですが、途中で処理速度が著しく落ちます。
クラスにしなかった場合とした場合とを比べるとクラスにしない場合の方が10倍ぐらい早いです。
何度もデバックしてみましたが原因不明です。
エラーもでないしなにがわるいんだろうか・・・・・

715 ：デフォルトの名無しさん：02/10/27 12:52

複数のスレッドが激しくCPUを奪い合うようになってたら、
シングルスレッドよりも遅くなるよ。

716 ：695：02/10/27 13:06

クラス化した理由はスレッドの関数を複数定義するのが面倒だし、スマートじゃない為でして、
＃クラス化しなくてもいい方法があるかもしれませんが・・
スレッドの数はクラス化する前も、した後も同じなので恐らく速度が落ちる事は無いと思うんですが・・

717 ：デフォルトの名無しさん：02/10/27 13:12

そりゃアンタのプログラムがバグってるか
アンタがバグってるかのどっちかじゃろうね

718 ：デフォルトの名無しさん：02/10/29 21:22

子スレッド中でのfork-execは、安全ですか?
ターゲットはLinuxおよびCygwinです。

719 ：718：02/10/29 21:31

pthreadsでは、fork直後のexecは安全であるべきと
いうことになっていたので逝ってきます。

720 ：デフォルトの名無しさん：02/10/30 00:51

Cygwinでpthreadはもうまともに動いているの？
少し前に聞いた話だと、バグだらけで使い物にならないとか。

721 ：デフォルトの名無しさん：02/10/30 02:13

>>720
バグ取りは随時やってるようだけど、「まともに動いている」という話は
最近でも聞かないねぇ。まぁ動けばめっけもん、くらいに考えておいた
方がいいんじゃないかな。

722 ：デフォルトの名無しさん：02/10/30 20:00

cygwinのpthreadならwindowsのAPIラップするだけじゃないの？
自体はそんなに簡単じゃないのかな？

723 ：デフォルトの名無しさん：02/10/30 20:48

UNIXエミュレーションとの整合を取る部分で死ねるのだと思われ

724 ：デフォルトは上限無しさん：02/10/31 00:01

>>722
そんなに簡単じゃない。
pthreadはpthread単独で意味があるわけでなく、
signal, I/Oなどなどとセットではじめて意味がある。
それぞれとの相互作用においてPOSIXに合っていなければ、
わざわざ使う意味がない。(Win32 APIでいいじゃんという意味において)

725 ：デフォルトの名無しさん：02/10/31 09:15

「APIラップするだけじゃないの」と疑問を抱くレベルなら
確かにAPI直接使えばよさげだ

726 ：デフォルトの名無しさん：02/10/31 09:20

Cランタイムとの整合性なんかを考慮してねえとまずくないかな

727 ：デフォルトの名無しさん：02/10/31 10:38

そらまずいだろうね。
ただまぁ最悪自分で同期取ればいい話でもあるが。

728 ：デフォルトの名無しさん：02/10/31 11:06

APIで上げたスレッドからは一切Cygwinの機能を使わなければ
なんとかなりそうだ

729 ：デフォルトの名無しさん：02/10/31 17:33

pthread仕事で使ってる人います？

730 ：デフォルトの名無しさん：02/10/31 17:39

使うかもしれないから調査中

731 ：デフォルトの名無しさん：02/10/31 20:31

Cygwinのsocketは、未だthread safeではなさげ(DLLのソース読んで確認)
ひとつのfdに対して複数スレッドでaccept(2)して、ひどいめに遭った

732 ：デフォルトの名無しさん：02/11/01 02:38

cygwinってfork使えますか？

733 ：デフォルトの名無しさん：02/11/01 02:50

fork遅いよ
っていうかスレ違いだろ

734 ：デフォルトの名無しさん：02/11/01 10:45

cygwinってspoon使えますか？

735 ：デフォルトの名無しさん：02/11/02 11:49

>>734
knifeなら使えます

736 ：デフォルトの名無しさん：02/11/12 19:32

Windowsであるクラスに参照カウントを持たせ、InterlockedIncrement./InterlockedDecrementで
マルチスレッド対応にしようとしたのだが…

void ref() {
　InterlockedIncrement(&m_ref);　
}
void release() {
　if (InterlockedDecrement(&m_ref) == 0) {
　　delete this;
　}
}

ところが、delete thisの直後にref()が呼ばれると、m_ref自体が解放された領域にあるため、
とんでもない値になってしまう。参照カウントをメンバー変数にするのが間違い?
どうしたらいんだろう？マルチスレッドのエキスパート様の降臨おながいします

737 ：デフォルトの名無しさん：02/11/12 19:55

> delete thisの直後にref()が呼ばれる

delete thisされたってことは、そのオブジェクトはもう参照されていない
と判断されたんだがら、その後にrefが呼ばれること自体がおかしい。

738 ：デフォルトの名無しさん：02/11/12 20:25

参照カウントを0から始めたに100スレッド

739 ：736：02/11/12 21:18

ある時点で、m_ref>0だったとします。
2つのスレッドが、それぞれ同時にref()とrelease()を呼び出すと…

740 ：デフォルトの名無しさん：02/11/12 21:24

ref() と release() が互いに排他してなきゃ動くわけないじゃん。

741 ：736：02/11/12 21:35

void ref() {
EnterCriticalSection(&m_cs);
　InterlockedIncrement(&m_ref);　
LeaveCriticalSection(&m_cs);
}
void release() {
EnterCriticalSection(&m_cs);
　if (InterlockedDecrement(&m_ref) == 0) {
　　delete this;
　}
LeaveCriticalSection(&m_cs);
}
としても、ref()でInterlockedIncrement()にたどり着いたときには…

742 ：デフォルトの名無しさん：02/11/12 21:57

あるオブジェクトに触れるスレッドが一つふえたら
そのオブジェクトの参照カウントをageておく必要があることに
気づいてないに1000はらたいら

743 ：デフォルトの名無しさん：02/11/12 21:58

＞739
それもなんだかおかしな動作だな。
refを発行する、というのは、どっかからobjectを貰ってきてるわけだろ。
で、releaseを発行するということは、所有権の一端を持っているわけだよな。
それで、deleteが実行されるというのは、
「refcount == 0かもしれないobjectが渡ってきた」
「release発行しすぎ」
ってなわけだろ。refするタイミングとか、考え直した方がいいんでないか？

744 ：736：02/11/12 22:36

refが参照カウントを増やす(objectを貰って来る)ためのものなのだが…

745 ：デフォルトの名無しさん：02/11/12 22:52

736はひょっとしてCOMを知らない？

746 ：736：02/11/13 10:05

いやCOMじゃなくて。
あるオブジェクトのインスタンスが作られるとm_ref=1となっていて、
そのオブジェクトを例えば別のスレッドが使うためにコピーを作るとm_ref=2
となる。
まさにその瞬間に、インスタンスの元のホルダーがオブジェクトを破棄しようとすると、
m_refのインクリメントとデクリメントが同時に起きる。
Interlocked...は同時じゃないが、ref()とrelease()が同時に呼ばれrelease()を
実行しているスレッドの方が早くCriticalSectionを獲得して解放したのち、
InterlockedIncrementが呼ばれると、解放されてしまうので値が不定になってしまう。

747 ：デフォルトの名無しさん：02/11/13 10:35

「別のスレッドが使うためにコピーを作る」ときに
「インスタンスの元のホルダーがオブジェクトを破棄」しちゃおかしいだろ。
「別スレッドに渡す」ときにコピーができるもんだろ、ふつー。

748 ：デフォルトは上限無しさん：02/11/13 10:42

>>746
Deleteされてしまうことがあるobject自身に、
objectの管理を「全て」任せようということ自体が無理。
Handler patternで行くか、refererにべたにcodeを書いてしまう。

749 ：デフォルトの名無しさん：02/11/13 10:44

つーかな。それはrefcountの問題と違うねん。たとえば、
method1() {delete str; str=0; }
method2() {func( *str );}

このメソッド２つが同時実行されるようなのとおなじ問題なわけよ。
あえて解決策を示すなら、

method1() {lock(); delete str; str = 0; unlcok(); }
method2() {lock() if( str ) func(str) unlock(); }

とかしないといけない。

750 ：デフォルトの名無しさん：02/11/13 11:21

ひょっとしてrefcountをさらにポインタや参照で管理しようとしてないか?
そんなのrefcountの意味が全くないぞ。根本的にrefcountについて誤解してるだろ。

751 ：デフォルトの名無しさん：02/11/13 11:28

>>750
俺もそんな気がして来た。グローバルなオブジェクトや静的なオブジェクトを
参照カウントでやろうとしてるような気もするし。

752 ：736：02/11/13 12:37

>746
やっぱり、そういう事になりますか。

>749
それは、ちっとも解決にならない。
method2がこの場合ref()なわけで、ref()から戻ったら、そのオブジェクト使おうと
するんだから。

>750
参照カウントは、扱われるインスタンス内に有りますが、
そのインスタンスを指すスマートポインターのようなクラスで持たなきゃならないって
事ですか?
そうでなくて、インスタンスと別にアロケートして参照カウント作ってもだめって事だけ?

>グローバルなオブジェクトや静的なオブジェクトを参照カウントでやろうとしてるような気もするし。
流石に、そんなこたぁない。

753 ：デフォルトの名無しさん：02/11/13 15:40

分からんヤツやな、、、
refする前にreleaseが発行されてrefcount==0になる
可能性があるなら、refする前に、oobjectが生きてて、
refできるか確かめないかんやろ。その結果、objectが
死んでるなら、refしてobject渡すのは諦めなアカン。
　で、そこでobjectが死んでるのが間違いなら、releaseか
refの発行の仕方がオカシイんや。

754 ：デフォルトの名無しさん：02/11/13 16:49

>>752
> >746
> やっぱり、そういう事になりますか。
ｼﾞｻｸｼﾞｴｰﾝ?

755 ：デフォルトの名無しさん：02/11/13 17:03

>>752
> 参照カウントは、扱われるインスタンス内に有りますが、
> そのインスタンスを指すスマートポインターのようなクラスで持たなきゃならないって
> 事ですか?
> そうでなくて、インスタンスと別にアロケートして参照カウント作ってもだめって事だけ?

場所は関係ない。ただし、インスタンスとカウンタの対応を管理することを考
えれば、インスタンス内に置くか「スマートポインターのようなクラス」って
のが確実で手軽だし常套手段。

参照が増減するたびに必ずカウンタも同期しなきゃ行けないってこと、わかっ
てる? これは本来アトミックな処理なので、別スレッドに渡すってのも参照を
増やすことになるんだけど、それとカウンタの更新を別スレッドに分けちゃい
けない。

単一スレッド内でコピーする場合は複製によるカウント処理が終るより前にオ
リジナルが解放することはないので保護されるけれど、別スレッドにしてしまっ
たらその順序が保証されなくなってしまう。

756 ：デフォルトの名無しさん：02/11/13 17:10

>>754
多分 748 宛てだと思われ。
レス番号と間違えてコメント先頭のポインタを書いてしまう間違いは漏れも時々
やってしまう。

757 ：736：02/11/13 17:30

なんか昨日から粘着が居るが

>753
>分からんヤツやな、、、
あんたほどでは（Ｗ

>refする前に、oobjectが生きてて、refできるか確かめないかんやろ。
確かめた時生きてても、じゃあ参照しようとしたら死んでる罠
確かめるときに参照かうんと増やす何て言うなよ（Ｗ

>755
>参照が増減するたびに必ずカウンタも同期しなきゃ行けないってこと、わかってる?
それは当然ですね。

>これは本来アトミックな処理なので、別スレッドに渡すってのも
別のスレッドに渡すのではなく、
あるスレッドAが参照カウントを持つOのインスタンスをつくって、
別のスレッドBがそのオブジェクトをもらおうとしたらば、
Aはもう要らないとOを破棄しようとしている最中だったわけです。

758 ：デフォルトの名無しさん：02/11/13 17:38

>>753
736 にはもう何も言わなくていいよ。
十分答え出てるのに見ようとしないんだから。

759 ：デフォルトの名無しさん：02/11/13 17:39

>>757
> 別のスレッドに渡すのではなく、
「渡す」つってんのはインスタンス自体じゃなくて参照のことをいってんだけど。
ポインタといったほうがいい?

> あるスレッドAが参照カウントを持つOのインスタンスをつくって、
> 別のスレッドBがそのオブジェクトをもらおうとしたらば、
この「もらおうとした」ってどういう状態を考えてるわけよ。
スレッドBはOのインスタンスo1に対する参照を受け取ってないわけ?
もし受け取ってるんならその時点でカウントしないとだめぽ。

760 ：736：02/11/13 18:22

>「渡す」つってんのはインスタンス自体じゃなくて参照のことをいってんだけど。
>ポインタといったほうがいい?
「渡す」というのは、あるスレッドAがインスタンスOの参照(カウントが増えた状態)を、別のスレッドB
がアクセスできるようにするという意味で使いました。
そうではなくて、スレッドAの預かり知らぬところで、スレッドBがインスタンスOを
コピー(の過程で参照化運とは増える)して使おうとするということです。

参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを
(クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた
わけです。

>758
そういうなら、参照カウント使ったクラスうｐしてみそ。逃げますか？（Ｗ

761 ：758：02/11/13 18:43

>>760
逃げる。
そしておまいは困る。ザマーミロ。

762 ：デフォルトの名無しさん：02/11/13 18:47

＞確かめた時生きてても、じゃあ参照しようとしたら死んでる罠
もう一度だけ言うぞ。

「確かめる」と「ref()呼ぶを」、一つのLock内でやれ。
もちろん、releaseの呼び出しにも、おなじLockをかけろ。
それでも、refcountが0になるなら、releaseを呼びすぎているだけ。

763 ：736：02/11/13 19:03

そんなに広い範囲でロックかけないで済む方法ってないの?

764 ：デフォルトの名無しさん：02/11/13 19:13

話してる前提が違うんじゃない？
>method1() {lock(); delete str; str = 0; unlcok(); }
が
method1() {lock(); delete this; /*this = 0;XXX*/ unlcok(); }
だから、method2()のifがそもそも出来ないという話

765 ：デフォルトの名無しさん：02/11/13 19:44

lock() str->release(); str = NULL; unlock();

766 ：デフォルトの名無しさん：02/11/13 19:44

>763
762のlockはそんなに広くないはずだが。

767 ：デフォルトの名無しさん：02/11/13 21:20

>>736
参照カウントが 1 のオブジェクトを複数のスレッドから参照してる時点で、
ref を呼び忘れてる。
参照回数0 のオブジェクトに到達することが正しい振る舞いだとしたら、
それは通常の参照じゃなく、弱い参照だ。

768 ：デフォルトの名無しさん：02/11/13 23:15

>>736
そもそも、スレッドが生きているかどうか分からないオブジェクトへの
ポインタを受け取ること自体に問題があるような。まさか、
スレッドA:
p = new クラス();
Bに渡す(p);
p->release();
スレッドB:
p = Aから受け取る();
p->ref();
というコードを書いていないだろうな？もしそうなら構造上の問題。
Bから見える場所にpを格納したなら、その分の参照カウントを数えなくては
ならない。それって本質的にはシングルスレッドでも同じことだけど。

769 ：デフォルトの名無しさん：02/11/13 23:23

> あるスレッドAが参照カウントを持つOのインスタンスをつくって、

COM知ってさえいれば・・・

770 ：デフォルトの名無しさん：02/11/13 23:24

つか、スレッドＢに渡されたことをどうやってＡは知るんだ？

771 ：デフォルトの名無しさん：02/11/13 23:31

>>770
普通Aがそれを知る必要は無いと思うが？
単にBが自分でディクリメントすればいいだけで。

772 ：デフォルトの名無しさん：02/11/13 23:58

なんか皆さん盛り上がってますが…
>>745 >>769に同意。
リファレンスカウントのサンプルを見たければCOMを勉強すればよい。
それと。日本語で一所懸命書かれてもどうにも伝わりにくいようですな。
C言語で（擬似コードでも可）書いた方が意図が伝わると思いますが。

773 ：デフォルトの名無しさん：02/11/14 00:03

>>760
> 参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを
> (クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた
> わけです。
そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って
カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し
てしまうというのはバグ。

774 ：デフォルトは上限無しさん：02/11/14 01:03

Guru of the Week!
Reference Counting - Part III (Multithreading!)
http://www.gotw.ca/gotw/045.htm

Reference Counting - Part I
http://www.gotw.ca/gotw/043.htm
Reference Counting - Part II
http://www.gotw.ca/gotw/044.htm

775 ：デフォルトの名無しさん：02/11/14 01:23

おまえらスレッド立てすぎです。

776 ：デフォルトの名無しさん：02/11/14 01:25

>>775
http://pc3.2ch.net/test/read.cgi/tech/997345868/515-516

777 ：775：02/11/14 01:38

>>776、禿同
マルチスレッド掲示板はやればやるほど
スレッドをsageる方向で書込みしたくなるという面白い側面がありますね。

778 ：デフォルトの名無しさん：02/11/14 01:48

この間ようやくプ逝１も sage を覚えたようですが

779 ：デフォルトの名無しさん：02/11/14 06:43

VC++の_beginthreadでプログラムを書いてるのですが
親スレッドから子スレッド(以後スレ)を10本同時進行で走らせていて、すべての処理が終った時
子スレの呼び出しの前に変数でフラグを立てておき、そのスレの最後でフラグをONにし、
親スレでそれを確認してからスレを終わるように処理を書いているのですが、
親スレで子スレのフラグを確認している最中に子スレが書き込みすると処理が停止してしまいます。
(デバックしてみるとその付近で停止したりしなかったりする)

このスレのどこかで参照は同時に行ってもかまわないようなレスをみたのですが(記憶が確かなら…)
同時書きこみでない場合(書き込み中を参照)でもだめなのでしょうか？
クリティカルセッション等やらねばダメなのでしょうか？

それともこのような設計が悪いのでしょうか・・

780 ：779：02/11/14 06:48

>>776
>マルチスレッドプログラミングは、やればやるほど
>スレッドを減らす方向に設計したくなるという面白い側面がありますね

私もスレッドにはうんざりですｗ
まぁ設計が悪いんでしょうが・・・

781 ：デフォルトの名無しさん：02/11/14 07:20

>>779
DQNは使うな
つーか、一冊でも参考書読め

782 ：779：02/11/14 07:31

よーくデバックすると原因が見つかりました。。^^;
長文書いたにもかかわらずすいません・・

後余談ですが、デバック中に子スレッドでconnect、closesocketを何度かやっていると
ある一定回数(かなりの回数)を超えた時、connectが出来ない状態になりました。
何らかのエラーが発生した場合そのエラーを表示するようにプログラムを
書いているのですが全く表示されません。
Socketの処理は居たってシンプルなもので、スレッドとは別で行っているのでバグは無いと思うのですが・・。
このような事は通常起こり得るのでしょうか？

783 ：736：02/11/14 10:50

どうして、参照カウントが増えた後の話にしたがるのか…

784 ：デフォルトの名無しさん：02/11/14 11:07

>765

>766
参照カウントを持つオブジェクトのリストがあって、追加・削除、参照(+そのための検索)
を行おうとすると、それぞれでリスト全部ロックしないと…
まあ、注目してるノードとその前後だけロックというのも有りうるけど面倒すぎる。
リスト自体が要素すうもってるし。

>767
参照できるようにする過程での話です。
参照カウントインクリメント不足は、お腹一杯。

>768
スレッドBのAから受け取る()は、どういう処理?
そのなかで、当然Mutexとかで排他制御して参照カウント増やすんでしょ?
その瞬間の話。

>769
実はCOMです。
COMのモジュール内で持ってる情報の管理でつまずいてる。
769はSTAだけつかってなさい。

785 ：デフォルトの名無しさん：02/11/14 11:11

>772
ちみもSTAだけつかってなさい。

> C言語で（擬似コードでも可）書いた方が意図が伝わると思いますが。
そいでは、>774の
Reference Counting - Part III (Multithreading!) http://www.gotw.ca/gotw/045.htm から

String::~String() {
　　bool bDelete = false;
　　data_->cs.Lock(); //---------------------------
　　if( data_->refs == Unshareable || --data_->refs < 1 )
　　　　bDelete = true;
　　data_->cs.Unlock(); //-------------------------
　　if( bDelete)
　　　　delete data_;
}

String::String( const String& other ) {
　　bool bSharedIt = false;
　　other.data_->cs.Lock(); //---------------------
　　if( other.data_->refs != Unshareable ) {
　　　　bSharedIt = true;
　　　　data_ = other.data_;
　　　　++data_->refs;
　　}
　　other.data_->cs.Unlock(); //-------------------
　　if( !bSharedIt )
　　　　data_ = new StringBuf( *other.data_ );
}
(つづく)

786 ：736=784=785：02/11/14 11:23

Sharable/Unsharableは置いといて、

Thread A　　　　　　　　　　　　　Thread B

delete O1呼び出し　　　　　　　　　O2 = O1 (otherがO1)

data_->cs.Lock();　　　　　　　　　other.data_->cs.Lock()
if (--data_->refs < 1)
　　bDelete = true;
data_->cs.Unlock();
if (bDelete)　　　　　　　　　　　　　data = other.data;
　　delte data;　　　　　　　　　　　　++data_->refs;
　　　　　　　　　　　　　　　　　　　　　other.data_cs.Unlock()

例のコードではStringなので、ロック後解放済みだったら空の文字列
を返せばよいのですが、実際には目的のデータであることを確認後
Thread BはO1のコピーのO2を手に入れようとしているので困ってます。

目的のデータがあるかどうかの検索の最初から、コピーを手に入れるまで
と解放処理を呼び出すのもまるっきり排他制御すればできるのは明らかで
すが、極端にパフォーマンスが落ちてしまいます。

787 ：736：02/11/14 11:26

>>773
> そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って
> カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し
> てしまうというのはバグ。

はぁー。
受け取る処理ってどうやるのさ?

>774
これからよく読んでみます。
ありがと。

788 ：デフォルトの名無しさん：02/11/14 11:27

>>786
> Thread A　　　　　　　　　　　　　Thread B

ここでBは既にO1への参照を持ってんだろ?

> delete O1呼び出し　　　　　　　　　O2 = O1 (otherがO1)

789 ：736：02/11/14 11:34

O1は、スレッド間で共有しているリスト中の要素としてある。

O2=O1は、そのリストから目的の物を検索して取り出す処理の中。

790 ：デフォルトの名無しさん：02/11/14 11:35

マルチスレッドのプログラムで
素朴リファレンスカウントGCをやるなら、
すさまじい細粒度ロックで効率が低下するのは
覚悟しなきゃ。

(普通のGCを使ったほうがずっと速いよ。)

791 ：デフォルトの名無しさん：02/11/14 11:53

>>789
やっぱりおかしいな。リストがStringを持ってるわけだろ？
それで、Thread Aがリストから要素を削除したら~String()が呼ばれる
わけだが、その前にThread Bがリストの要素への参照を持ってるなら
参照カウントは2になってなきゃおかしい。

こういうことするなら、当然文字列を指す可能性のあるオブジェクト
全部にリファレンスカウント付けて管理してるんだろ？

792 ：デフォルトの名無しさん：02/11/14 11:58

そうか。Stringというより
GarbageCollectedというスマートポインタを作って、
ヒープのオブジェクト全部GarbageCollectedを継承するように
するんだな。

そして、リストの検索とかやるときは、１つ１つの要素を
ロック・ref++・アンロック、ロック・ref--・アンロックすると。

793 ：デフォルトの名無しさん：02/11/14 12:21

>>789
もしかして
「排他制御せずにリストにアクセスしたら、変になるんですけど。」
って言ってる？

スレッドAがリスト中のO1を削除するには、

list.remove(index)

あるいは

list.remove(O1)

スレッドBがO1のコピーを作るには、

O2 = list.get(index)

だよな？
で、この get と remove はロックを使わずやりたいと。
そういうことか？

794 ：736：02/11/14 12:31

>791
>その前にThread Bがリストの要素への参照を持ってるなら
>参照カウントは2になってなきゃおかしい。

リストの要素への参照とは?
O1がそれだと言っているのか（Ｗ

>793
>で、この get と remove はロックを使わずやりたいと。
>そういうことか？
そう。
でも、
>「排他制御せずにリストにアクセスしたら、変になるんですけど。」
という事じゃない。
removeで要素中のO1は削除されるけど、Thread BがO2を手に入れていれば
O1-+
　　+-->ref:2,data:"ABC"
O2-+

から
O2---->ref:1,data:"ABC"

となり、他のスレッドは、もはやこのデータにアクセスできないが、
Thread BはO2から使える。O2が不要になって破棄したら、データ本体も解放される。

795 ：デフォルトの名無しさん：02/11/14 12:37

リスト操作たるgetとremoveにlockかけんかったら、
そいつらが平行したらあぼーんちゃうの。

まあ、「いや、実は～」とかいって
新状況が出てくるのかも知らんけど(ﾜﾗ

796 ：デフォルトの名無しさん：02/11/14 15:34

>>755で
> 参照が増減するたびに必ずカウンタも同期しなきゃ行けないってこと、わかっ
> てる? これは本来アトミックな処理なので、
と書いてある意味分かんないのか?

>>789
> O2=O1は、そのリストから目的の物を検索して取り出す処理の中。
てんなら、その処理中での参照の追加とカウントの増加は原理的に(そのオブ
ジェクトに対する)排他処理は必須ってことなんだが。

797 ：デフォルトの名無しさん：02/11/14 15:42

「getしてO1の参照先のref countが増える」までが
アトミックに行われないとまずいね。

getが返すべきO1を得た後で、かつO1のrefが増える前にrefがゼロに
なっちゃう。

やはり、
・リスト全体にmultiple-readers-single-writer lockをかける。
・リストの要素１つ１つに排他的ロックをかける。
のどちらかが必須。

798 ：デフォルトの名無しさん：02/11/14 15:50

>>796 禿同
getの中で「注目してるオブジェクト」を示すポインタが
あれば、そいつの参照も数えるべき。
あるオブジェクトを指す変数がある瞬間に３つあるなら
(たとえば「リストから」「Thread Aの局所変数から」
「Thread Bの局所変数から」)、参照カウントはその瞬間
３でないと間違い。

799 ：デフォルトの名無しさん：02/11/14 20:52

>>784 (=783?)
>実はCOMです。
>COMのモジュール内で持ってる情報の管理でつまずいてる。

COM扱っててこの有様は信じられない。

800 ：736：02/11/14 21:27

>796
未だに問題のポイントがわかってない言語障害者が居ますね。

>797
やっぱり、そうなっちゃいますかね。

>799
COMは関係なかろう、STAならInterlock何かする必要無いし、
そうでなければ、COMでも同じ。

801 ：デフォルトの名無しさん：02/11/14 21:44

ふつーのGC使えば、誤爆開放しちゃうdangling pointer問題からは
逃れられる。

でも、２人が同時にリストにあぷデートに行ったらどうやっても
ロック必須だけどナー

802 ：デフォルトの名無しさん：02/11/14 22:05

なんか禿しく釣られまくったような気がしてきた…。

803 ：デフォルトの名無しさん：02/11/14 22:17

ところでReadWriteLockでスタベーションフリーでLockのUpgrade/Downgradeも
できるようなの誰か知らんか？

804 ：デフォルトの名無しさん：02/11/14 22:20

>>736
考え方おかしいよ。
管理する側とされる側がごっちゃになってる。
そもそもdelete後に破棄されたインスタンスの排他制御
オブジェクトを参照しようとしてる事をおかしいと思わないの？

805 ：デフォルトの名無しさん：02/11/14 22:28

便乗で質問です。
スレッド間で、GC(インクリメンタルなマーク&スイープ)で管理された
共有領域のメモリオブジェクトを使いたいんですが、メモリオブジェクト
にはアクセスする度に排他制御しないといけませんよね？
参照するだけなら不要なのはわかるんですが、ポインタを繋ぎ変えたりも
したいので、結局双方でロックしてないと駄目ですよね。

素直に組むと、メモリオブジェクトの粒度が小さいので排他制御にかなり
の時間が割かれてしまいそうなんですが、良い方法はないでしょうか。
素人考えで思いついたのは、スレッド毎にローカルなメモリオブジェクト
領域を使って、処理が完了したら、その結果を共有メモリオブジェクト
領域に移すという方法で、排他制御は共有メモリにアクセスするとき
のみ掛けるというものですが、この方法だとスレッド毎にGCが必要な気が
します。
もっと一般的な方法があったらお願いします。

806 ：デフォルトの名無しさん：02/11/15 01:09

>>805
読むだけなら排他制御は不要だよ。
整数や文字を書き込むときも（共有変数以外は）不要。
ポインタを書いたときはライトバリアでGCに通知。
これも別に排他制御はいらない。たとえばスレッドごとにキューを作って、
ページ単位とかでまとめて渡せばよい。

807 ：805：02/11/15 03:22

>>806
ありがとうございます。
ライトバリアでマークする経路を保証するって事ですよね。
共有領域とローカルの区別をする手段が思いつかない(複数
ブロックにまたがってる)んで、改竄個所を全部保護する様に
書き直さないとまずいのかな。
ちょっと考えてみます。

808 ：デフォルトの名無しさん：02/11/15 03:25

ヒープに置くポインタはすべて
template Pointer<class T> ...
みたいなオブジェクトにして、コピーコンストラクタ
でライトバリアをかければよいんじゃないだろうか。

809 ：736：02/11/15 10:43

>804
頭おかしいよ。
こんなのどこにでもある。見たこと無いのか?

810 ：デフォルトの名無しさん：02/11/15 10:55

>>736
何人もの人間が否定してるんだから、おかしいのはお前だろ(笑

811 ：736：02/11/15 11:23

じゃあ、COMもおかしいのか?

812 ：デフォルトの名無しさん：02/11/15 11:49

>>809
「どこにでもある」が「おかしくない」の理由には全然ならない事に気付け。
つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな
サンプルに見舞われてるんだな。

>>811
おかしいのは COM を把握してないのにわかったつもりになってるあんたの頭。

つーか、教えを乞う立場だったら、もっと謙虚になれ。
主観を捨てろ。
答えへのポインタはもう不必要なほど出ているのに、あんたはそれを全部捨てている。

813 ：736：02/11/15 12:24

>812
>つーか、教えを乞う立場だったら、もっと謙虚になれ。

共有しているオブジェクトの集合に丸ごとロックかけずに、
各オブジェクトの参照カウントだけで済むかがポイントなのに、

参照カウントのインクリメント不足だとか、
COMを知ってればとか、
おんなじ事おんなじ事おんなじ事おんなじ事ばかーーーり。
しつこつしつこくしつこーーーーく同じこと繰り返す粘着が多くてウンザリ。

getはアトミックだとか…あのなあ、それ自体はアトミックでもremoveとgetを同時に呼ぶことは出来るんだよ。
参照を持っているならとか…あのなあ、その参照を受け取るのがgetだろ。共有オブジェクトのgetなんだよヴォケ。
じゃあ、参照を手に入れる処理を書いてみろというと、とたんに逃げ出す。
どうしてポイントがずれた香ばしい奴が多いのか。

814 ：736：02/11/15 12:26

>812
>「どこにでもある」が「おかしくない」の理由には全然ならない事に気付け。
>つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな
>サンプルに見舞われてるんだな。

これ見たこと無いか?
static ULONG WINAPI Increment(LPLONG p) {return InterlockedIncrement(p);}
static ULONG WINAPI Decrement(LPLONG p) {return InterlockedDecrement(p);}

ULONG InternalAddRef() {
　return _ThreadModel::Increment(&m_dwRef);
}

ULONG InternalRelease() {
　return _ThreadModel::Decrement(&m_dwRef);
}

STDMETHOD_(ULONG, AddRef)() {return InternalAddRef();}
STDMETHOD_(ULONG, Release)() {
　ULONG l = InternalRelease();
　if (l == 0)
　　delete this;
　return l;
}
まあ、君のコードの中では、
static ULONG WINAPI Increment(LPLONG p) {return ++(*p);}
static ULONG WINAPI Decrement(LPLONG p) {return --(*p);}
しか使われないと思うが（Ｗ

815 ：デフォルトの名無しさん：02/11/15 12:37

736の、これまでの発言で推測できること。
1.listでCOM objectを束ねているらしい
2.list内のあるCOM objectに対して、
　releaseとrefが(release->refの順で)発生して死ぬようだ
3.list全体に対するlockはかけたくないらしい
　(listが持つCOM objectに対する個々のロックは可能みたい？)

736の発言だけで、この問題がわかるかってーの。
それを736の時点で言えば、まだ混乱は少なかっただろうに。
変に情報を出し惜しむから、おなじ事をしつこく何度も
言われる羽目になる。おまけに自分のことを棚に上げて
しつこいとか、ポイントがずれてるとか、香ばしいとか言うし。

816 ：736：02/11/15 12:40

それで？

817 ：デフォルトの名無しさん：02/11/15 12:42

で、815であげた推測は正しいのかい？
というか、コードだせ、コード。問題の起こる、
必要最小限の、736の書いたコードを。

818 ：736：02/11/15 12:44

738 ：デフォルトの名無しさん：02/11/12 20:25
参照カウントを0から始めたに100スレッド

740 ：デフォルトの名無しさん：02/11/12 21:24
ref() と release() が互いに排他してなきゃ動くわけないじゃん。

742 ：デフォルトの名無しさん：02/11/12 21:57
あるオブジェクトに触れるスレッドが一つふえたら
そのオブジェクトの参照カウントをageておく必要があることに
気づいてないに1000はらたいら

743 ：デフォルトの名無しさん：02/11/12 21:58
＞739
それもなんだかおかしな動作だな。
refを発行する、というのは、どっかからobjectを貰ってきてるわけだろ。
で、releaseを発行するということは、所有権の一端を持っているわけだよな。
それで、deleteが実行されるというのは、
「refcount == 0かもしれないobjectが渡ってきた」
「release発行しすぎ」
ってなわけだろ。refするタイミングとか、考え直した方がいいんでないか？

745 ：デフォルトの名無しさん：02/11/12 22:52
736はひょっとしてCOMを知らない？

747 ：デフォルトの名無しさん：02/11/13 10:35
「別のスレッドが使うためにコピーを作る」ときに
「インスタンスの元のホルダーがオブジェクトを破棄」しちゃおかしいだろ。
「別スレッドに渡す」ときにコピーができるもんだろ、ふつー。

819 ：736：02/11/15 12:44

750 ：デフォルトの名無しさん：02/11/13 11:21
ひょっとしてrefcountをさらにポインタや参照で管理しようとしてないか?
そんなのrefcountの意味が全くないぞ。根本的にrefcountについて誤解してるだろ。

751 ：デフォルトの名無しさん：02/11/13 11:28
>>750
俺もそんな気がして来た。グローバルなオブジェクトや静的なオブジェクトを
参照カウントでやろうとしてるような気もするし。

753 ：デフォルトの名無しさん：02/11/13 15:40
分からんヤツやな、、、
refする前にreleaseが発行されてrefcount==0になる
可能性があるなら、refする前に、oobjectが生きてて、
refできるか確かめないかんやろ。その結果、objectが
死んでるなら、refしてobject渡すのは諦めなアカン。
　で、そこでobjectが死んでるのが間違いなら、releaseか
refの発行の仕方がオカシイんや。

820 ：736：02/11/15 12:45

767 ：デフォルトの名無しさん：02/11/13 21:20
>>736
参照カウントが 1 のオブジェクトを複数のスレッドから参照してる時点で、
ref を呼び忘れてる。
参照回数0 のオブジェクトに到達することが正しい振る舞いだとしたら、
それは通常の参照じゃなく、弱い参照だ。

769 ：デフォルトの名無しさん：02/11/13 23:23
> あるスレッドAが参照カウントを持つOのインスタンスをつくって、

COM知ってさえいれば・・・

772 ：デフォルトの名無しさん：02/11/13 23:58
なんか皆さん盛り上がってますが…
>>745 >>769に同意。
リファレンスカウントのサンプルを見たければCOMを勉強すればよい。
それと。日本語で一所懸命書かれてもどうにも伝わりにくいようですな。
C言語で（擬似コードでも可）書いた方が意図が伝わると思いますが。

773 ：デフォルトの名無しさん：02/11/14 00:03
>>760
> 参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを
> (クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた
> わけです。
そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って
カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し
てしまうというのはバグ。

821 ：デフォルトの名無しさん：02/11/15 12:48

736 荒らしｹﾃｰｲ
（いや、元々そうだったという説もあるが・・・）

という訳で出て逝ってくれ。

822 ：736：02/11/15 12:51

君らのしつこさを確認させてやっただけだよ

823 ：デフォルトの名無しさん：02/11/15 12:53

( ´，_ゝ｀)ﾌﾟッ

824 ：736：02/11/15 12:58

結局誰も判らんのか。それならそう言えよ無能者ども。

825 ：デフォルトの名無しさん：02/11/15 13:00

>>822
あのさあ、
しつこいのは　お　ま　え　（ｗ
消えろ

826 ：デフォルトの名無しさん：02/11/15 13:03

>>813
> 共有しているオブジェクトの集合に丸ごとロックかけずに、
> 各オブジェクトの参照カウントだけで済むかがポイントなのに、
参照カウントのインクリメントにはロックは*原理的に*必要不可欠。
してないのはシングルスレッドを前提にしてる場合だけ。
わかった?

> 参照カウントのインクリメント不足だとか、
> COMを知ってればとか、
> おんなじ事おんなじ事おんなじ事おんなじ事ばかーーーり。
> しつこつしつこくしつこーーーーく同じこと繰り返す粘着が多くてウンザリ。
なんでおんなじ事をこんなにしつこく説明してやらなきゃならんのか…。

> getはアトミックだとか…あのなあ、それ自体はアトミックでもremoveとgetを同時に呼ぶことは出来るんだよ。
> 参照を持っているならとか…あのなあ、その参照を受け取るのがgetだろ。共有オブジェクトのgetなんだよヴォケ。
そのアトミックなgetにカウントのインクリメントを含めてないからバグって
んだろが。

827 ：736：02/11/15 13:07

まだ言ってるのか。
>参照カウントのインクリメントにはロックは*原理的に*必要不可欠。
>してないのはシングルスレッドを前提にしてる場合だけ。
>わかった?

void ref() {
EnterCriticalSection(&m_mutex);
　InterlockedIncrement(&m_ref);　
LeaveCriticalSection(&m_mutex);
}
void release() {
EnterCriticalSection(&m_mutex);
　if (InterlockedDecrement(&m_ref) == 0) {
　　delete this;
　}
LeaveCriticalSection(&m_mutex);
}
としたら満足か？（Ｗ

828 ：736：02/11/15 13:09

>826
おまえ、InterlockXXってなんのためにあるのか知らんだろ。
知らない奴に限って、無駄なレスを返しやがる。

829 ：デフォルトの名無しさん：02/11/15 13:12

としたら満足か、って・・・
一体何の為にここに質問に来たんだ？

830 ：デフォルトの名無しさん：02/11/15 13:17

736の無能っぷりをさらけ出すスレはここですか？

>>837
>EnterCriticalSection(&m_mutex);
>　InterlockedIncrement(&m_ref);　
>LeaveCriticalSection(&m_mutex);

クリティカルセクション張ってるんだから、
インターロック不要なんだけど。

>EnterCriticalSection(&m_mutex);
>　if (InterlockedDecrement(&m_ref) == 0) {
>　　delete this;
>　}
>LeaveCriticalSection(&m_mutex);

自分で書いてておかしいと思わないのかなあ・・

831 ：736：02/11/15 13:21

>>836

あのなあ、

>>参照カウントのインクリメントにはロックは*原理的に*必要不可欠。
>>してないのはシングルスレッドを前提にしてる場合だけ。
>>わかった?

というのは読めないのか。お前は、自然言語にたいする理解力は０だな。
ロックかけなきゃだめだと言ってるやつがいるから、ロックしたまで。
なーんの解決にもならんし、もともと、Interlockしてるから不要なんだがな。

832 ：736：02/11/15 13:21

>830
だわ

833 ：736：02/11/15 13:23

で？８２６も逃げたのか。全く都合が悪くなると逃げて…自分の発言に席にもてよ。
どうせ、別人のフリしてまた別の事言い出すんだろうが

834 ：736：02/11/15 13:26

ん？deleteまではロックしなきゃダメかな。
まあ、どのみちref()でロック獲得したときに、解放済みというのは避けられんが。

835 ：デフォルトの名無しさん：02/11/15 13:28

>>827
> としたら満足か？（Ｗ
で、バグは直ったのか? 漏れが満足したからってバグが消えるわけじゃないぞ。

void Item::ref() {
　InterlockedIncrement(&m_ref);　
}
Item* List::get() {
EnterCriticalSection(&m_mutex);
Item* p = ...;
p->ref();
LeaveCriticalSection(&m_mutex);
return p;
}
この例で行くとListのget()とremove()で競合が起きるんだろ?
ならListのほうで排他処理をするのが自明の理。

836 ：736：02/11/15 13:34

やっぱり、List::get()でリストの検索処理が丸ごとロックするしかないのか。

837 ：デフォルトの名無しさん：02/11/15 13:40

(´-`).｡ｏＯ(100レスかけてようやく染み込んだのか)

838 ：736：02/11/15 13:49

それ以外に無いのか聞いてんだが。
ここのいる連中じゃ無理のようだ（Ｗ

839 ：736：02/11/15 13:53

>812
>「どこにでもある」が「おかしくない」の理由には全然ならない事に気付け。
>つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな
>サンプルに見舞われてるんだな。

８１２も逃げたようだな。逃げ足の速い連中だ。

840 ：デフォルトの名無しさん：02/11/15 14:07

>>838
> それ以外に無いのか聞いてんだが。
散々いわれてんのに。>>762とか>>785とか。
大体間接的に渡すって話自体>>789くらいでいきなりだし。

>>839
> ８１２も逃げたようだな。逃げ足の速い連中だ。
いつまでも君の相手してらんないしね。
漏れもそろそろ出かけなきゃならないんでバイバイ。

841 ：デフォルトの名無しさん：02/11/15 14:27

winでのTerminateThreadと同じような
関数はunixにありますか？

842 ：デフォルトの名無しさん：02/11/15 14:38

pthreadならpthread_cancel()かな。TerminateThreadと違って必ずしも即座に
終了するわけじゃないけど。

843 ：デフォルトの名無しさん：02/11/15 14:44

教えて下さい。
pthread_cancel()を実行すると
実行されたスレッドの終了はいつになるのですか？

844 ：デフォルトの名無しさん：02/11/15 14:47

実行してみればわかる

845 ：736：02/11/15 15:06

>840
またバカが湧いてきた。

>散々いわれてんのに。>>762とか>>785とか。
>762は、各オブジェクト毎にロック掛けるって意味ならロックが多量に必要だし、リストにはロック掛けないのか？
リストにロックかけるんだったら、各オブジェクト毎に掛ける必要なし。
君のような厨には理解で菌だろうがな。

>大体間接的に渡すって話自体>>789くらいでいきなりだし。
間接的?ハァ?頭大丈夫?

785は俺だ。
たくっ。ろくに読まないでレスするアホウは書くなっつの。

>いつまでも君の相手してらんないしね。
>漏れもそろそろ出かけなきゃならないんでバイバイ。

いや、君みたいなアホウに相手してくれとは言ってないから（Ｗ
お呼びでないの（Ｗつか出てくんなっての

大体、レスして何か言われたら自分が誰かわかるように名前に番号入れるもんだろ。
言いっぱなしで自己満足してる厨が多すぎ。

846 ：736：02/11/15 15:16

740 ：デフォルトの名無しさん：02/11/12 21:24
ref() と release() が互いに排他してなきゃ動くわけないじゃん。

826 ：デフォルトの名無しさん：02/11/15 13:03
>>813
> 共有しているオブジェクトの集合に丸ごとロックかけずに、
> 各オブジェクトの参照カウントだけで済むかがポイントなのに、
参照カウントのインクリメントにはロックは*原理的に*必要不可欠。
してないのはシングルスレッドを前提にしてる場合だけ。
わかった?

こういう連中は、
void ref() {
　EnterCriticalSection(&m_cs);
　++m_ref;
　LeaveCriticalSection(&m_cs);
}
void release() {
　EnterCriticalSection(&m_cs);
　if (--m_ref) == 0) {
　　delete this;
　}
　LeaveCriticalSection(&m_cs);
}

って書いてるのかな。馬鹿だなー。
こんな事言ってる奴が多いのは　オ　ド　ロ　キ。
もはや都市伝説だな。

847 ：736：02/11/15 15:17

おっ！
830が、慌ててネットで調べ始めた。まあ、自分の馬鹿さ加減を思い知れ。

848 ：736：02/11/15 15:21

おっ！
他にもInterlockだけじゃダメだと思ってる奴も多いな。
まあ、release()のLeaveCriticalSectionがdelete以降なのは論外だが、
void ref() {
　InterlockedIncrement(&m_ref);　
}
void release() {
　if (InterlockedDecrement(&m_ref) == 0) {
　　delete this;
　}
}
じゃだめだと思ってるやつは何か言ってみろ。
どうせ逃げんだろうけどな。

849 ：デフォルトの名無しさん：02/11/15 15:34

void ref() {
　InterlockedIncrement(&m_ref);　// A
}
void release() {
　if (InterlockedDecrement(&m_ref) == 0) {
　　// B
　　delete this;
　}
}
B のタイミングで A が呼ばれた場合。

850 ：デフォルトの名無しさん：02/11/15 15:45

void ref() {
　InterlockedIncrement(&m_ref);　// A
}
void release() {
　if (InterlockedDecrement(&m_ref) == 0) {
　　delete this;
　　// C
　}
}
C のタイミングで A が呼ばれた場合。

しかし、危険性において 846 のコードは結局 848 と変わらないな。

851 ：736：02/11/15 15:48

おいおい、本当にのこのこ出てきたよ。恥ずかしい奴だ。

852 ：736：02/11/15 15:50

>しかし、危険性において 846 のコードは結局 848 と変わらないな。
説明してみろよ。わくわく。
Bのところに行くのは、どういう場合さ?

853 ：デフォルトの名無しさん：02/11/15 16:01

>８４９
馬鹿です。

854 ：デフォルトの名無しさん：02/11/15 16:01

晒しage

855 ：デフォルトの名無しさん：02/11/15 16:02

＞>762は、各オブジェクト毎にロック掛けるって意味ならロックが多量に必要だし、リストにはロック掛けないのか？
＞リストにロックかけるんだったら、各オブジェクト毎に掛ける必要なし。
＞君のような厨には理解で菌だろうがな。

つか、762の時点では、そもそもリストが使われていることが
説明されていないわけで、762の時点で「リストにもロックかけろよ」
と言えるなら、そいつは神

856 ：736：02/11/15 16:03

あげてねーじゃん

857 ：736：02/11/15 16:04

>855
リストである必要なし。
グローバル変数など共有してれば同じ。
この場合動的じゃなきゃ意味無いが。

858 ：デフォルトの名無しさん：02/11/15 16:08

何がおなじなんだか、、、

859 ：デフォルトの名無しさん：02/11/15 16:10

思うんだが、ref() を bool 型にして、呼び出し側で false を受け取ったら取得を諦める
ようにはできないのか？

bool m_sw1st; // コンストラクタで true に
bool ref() {
　bool ret = true;
　EnterCriticalSection(&m_cs);
　if(!m_ref)
　{
　　if(m_sw1st)
　　　m_sw1st = false;
　　else
　　　ret = false;
　}
　if(ret)
　　++m_ref;
　LeaveCriticalSection(&m_cs);
　return ret;
}
void release() {
　EnterCriticalSection(&m_cs);
　if (--m_ref) == 0) {
　　delete this;
　}
　LeaveCriticalSection(&m_cs);
}

参照カウンタが 1 始まりなら m_sw1st は要らないけど。

860 ：859：02/11/15 16:14

ごめん、無かった事にして。

861 ：736：02/11/15 16:13

m_csってメンバー変数じゃないのか?
ref()のEnterCriticalSectionでブロックされてるときに
deleteされるのは大丈夫か?
首尾よく、ref()でCriticalSectionに入れてもm_refは不定だぞ。

862 ：736：02/11/15 16:16

で？849はやっぱり逃げたのか。

863 ：デフォルトの名無しさん：02/11/15 16:17

ここはすごいITパワーですね。

864 ：デフォルトの名無しさん：02/11/15 16:23

＞838
だから、無いんだって。intのlistを考えてみろよ。
lockしないで、検索処理と、削除処理を併走できるかっつーの。

865 ：デフォルトの名無しさん：02/11/15 16:28

>864
リストなら丸ごとロックしなくてもできる。

866 ：736：02/11/15 16:30

>865
と言うと?

>864
おい！あるってぞ。言い返せよ。

867 ：デフォルトの名無しさん：02/11/15 16:33

別に言い返さないさ。
自身の不明を恥じて、詳細を拝聴するだけサ。

868 ：865：02/11/15 16:47

例えば、リストの3番目を削除しようとしている時には、検索処理が4番目以降の要素を
見ているなら同時に動いて問題ない。検索処理が、ちょうど3番目の要素を見ようとしているか
3番目から4番目に移ろうとしている時だけが同時に動けないだけ。
どのみち、要素数とか持っているリストだと同時に複数が書き込めないから、
たかだか一つの要素だけ排他制御できさえすればよい。

869 ：デフォルトの名無しさん：02/11/15 17:02

リストの項目が増えた時、リスト丸ごとのロックと、項目ごとのロックでは、
どっちが速いんだろうか。

870 ：　：02/11/15 17:09

>>869

そういうものの定石を適用すると、リストを示すポインタ値を適当にハッシュして16個くらいの
ロックに分散させる、てな感じにするんだと思うよ。一要素毎にロックを持つのはリソースを食
うし、あまりぶつからない程度に分散させれば十分だから。

871 ：デフォルトの名無しさん：02/11/15 17:13

>869>870
865が言っているのは、要素毎にロック作らなくても、
同時書き込み無しなら、一つロックがあればいいということだろ。
丸ごとロックしなくても、ロック一つでWriterはReaderと共存(Readerがいなく
なるまでまたなくても)できると。

872 ：デフォルトの名無しさん：02/11/15 17:16

＞871
ロックが一つしかないなら、どうやって、
「今削除しようしている所を読んでるreaderがいない＆
readerは削除しようとしている所へ進入しない」って
保証できるん？

873 ：736：02/11/15 17:18

それは、16スレッドが同時に書き込めるのか?
各スレッドが別の要素にアクセスするとして。

リストが要素数なんか持ってても大丈夫?
単純なリストならまだしも、空リストとか管理されてると結局その中の
一つのスレッドしか書き込みできない(というか排他制御が必要な)気がするが。

874 ：871：02/11/15 17:26

>872

writerは要素の変更じゃ無くて、要素の追加・削除を行うとして。
writerが削除しようとしている要素とかその次の要素の場所を書いとけば、
readerはそれみて何とかできる気がするが。
writerが削除しようとしている要素はすっ飛ばすとか。

追加は先頭でも最後でも問題起きないと思うが。
どっちにしろ、readerはwriterがする事を知っているのが前提で、
汎用ではなく。

875 ：872：02/11/15 17:27

ひょっとして、readerの数だけの、index/pointerを指している
配列と、その配列全体に対するロックがあれば解決できる話
なのか？

876 ：デフォルトの名無しさん：02/11/15 17:33

＞874
それだと、「削除されるべき場所にいるreader」が、
「『リストの次の要素へ』を発行すること」をどう保証するか、
writerはどう検出するかって問題になるとおもうけど、、

877 ：デフォルトの名無しさん：02/11/15 18:00

５０年前の並列処理問題を一から学び直す
ドキュソPGのスレはここですか？

878 ：デフォルトの名無しさん：02/11/15 18:06

>877
(　´д)ﾋｿ(´д｀)ﾋｿ(д｀ )

879 ：デフォルトの名無しさん：02/11/15 18:48

lock free linked list
なんつって

880 ：768だけどさあ：02/11/15 20:02

分からん奴だなあ。
リストの排他制御と、参照カウントの問題と、参照カウントの
排他が全部ごっちゃになっている時点でもう駄目。
まず、リストに複数スレッドからアクセスするなら、そのリストの
どこかに排他入れなきゃ駄目なの。次に、問題の共有オブジェクト
はリストからの参照の分があるから、リストに繋がっている間は
参照カウントは常に1以上でなきゃ駄目なの。「見付けた」時点では
「リストの方が」排他されているから、この間に参照カウントを増やそうね。
リストの排他が終わった時点で、参照カウントは2以上だから、この後
リストからremoveされても平気だよね。(ここが768の「Bから見える場所に
云々」ということの意味。)第三に、参照カウントも複数のスレッドから
参照されるから、これも排他しなくちゃならないよね。これはさすがに
分かってるみたいだけど。

881 ：736：02/11/15 21:01

お前ら無能すぎ。そんな程度で２ちゃん来てんじゃねーよ。

882 ：デフォルトの名無しさん：02/11/15 21:07

ところで、881は何人目の736ですか？

883 ：870：02/11/15 21:08

>>873

何への質問だかわからないけど、16っていうマジックナンバーがあるから
870 だと仮定して答える。

「リストから remove 」等の処理に排他制御をかけるとして、ごく素朴な
リスト全体にたいしてロックが１つ、という状態では競合が起きた場合に
素直にパフォーマンスが悪化する。並列性が高くなればなるほど競合の可
能性は増し、結局並列動作できない場面が出てくる。

その辺をチューニングする場合の定石として、適当にロックの数を増やす
ってのがある。コンテキストスイッチングに比べて排他の対象となる操作
の方が十分重い場合には、寝てるスレッドのことはほぼ無視しても良いの
で、CPU の数＋αに分散させれば十分。そうじゃないときは多めにする。

884 ：870：02/11/15 21:11

>>849-850

そのタイミングで当該オブジェクトへのアクセスが発生するって思うのは、
参照カウントというものが何であるのかをわかっていないと思う。

そらまあそーいうこともあるだろうケド、その場合呼び出し側がバグって
るわけで。

885 ：736：02/11/15 21:13

>>881
とうとう偽者まで出てきたか。

886 ：736：02/11/15 21:13

適当ほざいてんじゃねーよ
帰って寝てろ
ﾜﾗﾜﾗ

887 ：736：02/11/15 21:16

881=882だろ。

>880
> 第三に、参照カウントも複数のスレッドから
> 参照されるから、これも排他しなくちゃならないよね。
どういう風に?(W

888 ：736：02/11/15 21:17

>886
おまえも881だろ。

>884=870

もうちょっと、説明してくれや。

889 ：736：02/11/15 21:18

騙ってまで何がやりたいんだか

>880
教科書のコピペはやめようね

890 ：元祖736：02/11/15 21:18

736増殖中

891 ：736本人：02/11/15 21:20

やめろっての。馬鹿がうつる。

892 ：元祖736：02/11/15 21:24

>>880
だぁから、そんなのあたりまえだろ。おまえはしらなかったかもしらんが。
そこを参照カウントに技使って、リストのロックに工夫できないかという話だったのが、
しつこくしつこくしつこーーく参照カウントのインクリメント不足だと
おんなじ事繰り返す厨の集団攻撃が始まっちまったんだよ。
しまいには、ref()とrelease()に排他制御が無いからだと言い出すドアホまで
何人も出てきやがるし。お前達は、お呼びじゃないんだよ。

893 ：870：02/11/15 21:25

reference counting ってのは、そのオブジェクトへの「参照」の数を
数えておいて、ゼロになったら誰も見てないから開放～てなアイデア。

だからカウントがゼロになった後は誰から参照されておらず、どんな
メソッド…メンバ関数も呼ばれないわけです。呼んだとしたらそれは
呼び出し側のバグ。

894 ：デフォルトの名無しさん：02/11/15 21:41

＞そこを参照カウントに技使って、リストのロックに工夫できないかという話だったのが、
736ではそんな話には読めない。最初からそう書けよ。

＞おんなじ事繰り返す厨の集団攻撃が始まっちまったんだよ。
自業自得

895 ：デフォルトの名無しさん：02/11/15 21:46

>そこを参照カウントに技使って、リストのロックに工夫できないかという話だったのが、
どんどん話が変わっているような。しかも参照カウントとオブジェクトを
参照しているリストなんて、参照カウントを増やすこと以外に全然関係
無いから、工夫なんてまず無理だろう。

896 ：デフォルトの名無しさん：02/11/15 21:47

誰か本物の736を連れ戻してくれよ

897 ：デフォルトの名無しさん：02/11/15 21:52

＞881=882だろ。
違いますよ。

898 ：デフォルトの名無しさん：02/11/15 21:56

だから参照カウントなんて腐った手法使うなって。

899 ：736：02/11/15 22:02

>898
ギブアップしたの?(W

900 ：デフォルトの名無しさん：02/11/15 22:52

だから最初から言ってるだろ？
参照カウントなんて使わずにまともなGC使えや。

901 ：デフォルトの名無しさん：02/11/15 23:15

参照カウントか、昔よくやってた。懐かしいな。マルチスレッドでうまく解けるか
自信ないけど…。

スレッド 1 がクリティカルセクションに入って参照カウントを 0 にしようとした
瞬間、別のスレッド 2 がカウントアップしようとクリティカルセクションで
ブロックに突入するからまずいんだろうな。同期ブロックに入っている数もカウント
しておいて、参照カウントと同期ブロックスレッド数が 0 になったところで初めて
開放すれば良いんじゃなかろうか。

…でも別スレッドからカウントアップ可能ということはそのスレッドから参照が残っ
てるってことだからやっぱり無理なのか? CPU 負荷などの影響でカウントアップ側の
処理が遅れたらアウトだもんな。んでもスレッド間での参照の「コピー」時にしっかり
カウントアップしてれば問題無いような。

参照カウントと循環参照について IBM に話が載ってるけどこれはガイシュツかいな。

http://www-6.ibm.com/jp/developerworks/java/000721/j_garbage-collection.html

902 ：デフォルトの名無しさん：02/11/15 23:39

参照を獲得する処理そのものがアトミックでなければいけない。
つまり、ref や release に到達する時点でそのオブジェクトに対する排他制御が
かかってなきゃいけない。それらのメソッドに入ってからでは遅い。

Object* List::get(int index){
　criticalSections_[index % 4].enter();
　Object* o = items_[index];
　if(o != NULL){
　　o->ref();
　}
　criticalSections_[index % 4].leave();
　return o;
}

void List::remove(index){
　criticalSections_[index % 4].enter();
　Object* o = items_[index];
　if(o != NULL){
　　o->release();
　　items_[index] = NULL;
　}
　criticalSections_[index % 4].leave();
　return o;
}

こんな感じか？

903 ：デフォルトの名無しさん：02/11/16 00:40

レスがたくさんついていると思ったら、、、

904 ：入門者だけど：02/11/16 01:05

本質的には参照カウントのことは関係なくて、参照が複数スレッドで
共有されていれば、その参照自体にも排他をかけなければならない
というだけの話だ、という理解で合ってる？

905 ：デフォルトの名無しさん：02/11/16 01:11

そもそもスレッド間で参照を代入するときにちゃんと参照数 +1 してれば
ゼロにはならないのでは?

906 ：デフォルトの名無しさん：02/11/16 01:18

>>905
>>742

あれから100以上もひっぱった736の連中、氏ね。

907 ：デフォルトの名無しさん：02/11/16 01:22

>>906
みんな同期問題の方に目がいっちゃってたね。

908 ：デフォルトの名無しさん：02/11/16 01:24

>>902
getって削除された要素を飛ばして次の要素を返すんじゃないか？
あと、removeが値を返してるよ。

>>905
その参照を増やす手段がgetなんだけど…

909 ：デフォルトの名無しさん：02/11/16 01:27

スレッドだけに限らず、とにかく「何ヶ所から指されてるか」
をちゃんと保持しないと。変数に代入したらちゃんと参照カウント
増やせ。

910 ：デフォルトの名無しさん：02/11/16 01:28

だから、参照カウント法はマルチスレッドにむちゃくちゃ不向き
なんだから、まともなGC使えってば...

911 ：デフォルトの名無しさん：02/11/16 01:35

>>908
スレッド A からスレッド B に参照を代入しようとしている。同時にスレッド C が
参照を開放しようとしている。

最初の時点で参照を持っているのは A と C だから参照数は 2、C がカウントダウン
したところで参照数は 1、そのあと B に代入されてカウントは 2 になる。

これのどこに参照数 0 になる要素があるか答えよ (同期化は当然行っている
とする)。

# と断言して俺が間違ってたら恥ずかしいわけだが…

912 ：デフォルトの名無しさん：02/11/16 01:38

単なる論理バグで 100 以上引っ張った悪寒

913 ：デフォルトの名無しさん：02/11/16 01:43

論理バグというより、勉強不足でしょ。

914 ：デフォルトの名無しさん：02/11/16 01:46

>>911
スレッドの数だけ数えりゃ良いわけじゃないって言うとるに。
ヒープ上のデータ(たとえばリスト)から参照されてて、
そのリストを指しているのはスレッドDだけだったとする。
あんたの数え方だと、スレッドAとBが参照を離したら、
リストから指されてるのに解放されちゃうよ。

また、同じスレッドの中でメソッド呼び出しに参照を渡した
とする。この時にも参照を増やさないと。呼び出された先で
参照が不要になったからって勝手にカウントダウンしたら
呼び出し元が困るだろ。

915 ：デフォルトの名無しさん：02/11/16 01:48

>>910
でも、C++みたいな言語でGCも怖い気がする。
GCのバグ云々じゃなく、相当気をつけて使わないと、GCと
例外機構やデストラクタが衝突してあぼーん、になりそうで
不安。Cの方がまだしも、処理系の動きが見えやすいだけ、
楽な気がする。

916 ：デフォルトの名無しさん：02/11/16 01:51

>>914
後半は普通につかってりゃありえんだろ

917 ：デフォルトの名無しさん：02/11/16 01:52

>>914
>あんたの数え方だと、スレッドAとBが参照を離したら、
>リストから指されてるのに解放されちゃうよ。
914をどう読むとそういう数え方になるんだ？
>また、同じスレッドの中でメソッド呼び出しに参照を渡した
>とする。この時にも参照を増やさないと。呼び出された先で
>参照が不要になったからって勝手にカウントダウンしたら
>呼び出し元が困るだろ。
それは弱い参照にするかどうかだよね。呼び出された先が、
どこにもその参照を突っ込まないで、カウントを変えないまま
リターンすれば問題ないわけで。
参照カウントの有難味は無くなるけど。

918 ：デフォルトの名無しさん：02/11/16 01:56

>>908
いや、index が識別子なのか単なる順序値なのかわからんし、
一応こうしといた。

remove は中途半端になっちまった。引数の型も抜けてるし。
中で release する場合と、オブジェクトを返して外で release する
場合と考えてた。

919 ：デフォルトの名無しさん：02/11/16 01:56

いくつの「スレッドが」参照してるかなんていう
数え方をするから間違える。

シングルスレッドでも参照カウントはちゃんと増減させるだろ？

とにかく「何ヶ所から指されているか」を正しく参照カウント
に反映させておかないと。

メソッド呼び出しではたしかに人間が推論して最適化すること
はあるね。間違いのもとだけど。

920 ：デフォルトの名無しさん：02/11/16 01:59

>>914
スレッド D が持つリストからも参照されてるなら初期状態での参照数は 3 だろ。
逝っておくがいくつのスレッドで共有されているかをカウントしているという意味
ではないぞ。

ただ循環参照になってるとどこからも使われてないのに参照数が残ってしまう
だろうな。単純な参照カウントの弱いところだ。

921 ：767=793=902：02/11/16 02:10

で、736 はどうした。問題は解決したか？
とりあえずリスト全体ロックは回避できたんだから、これくらい(複数のロックを使う)で
手を打つのがよいと思うのだが。

あとは、refcount が 0 になってもその場では削除せず、後で回収するくらいしか
無いと思う。もちろん回収の時は、全スレッドを安全な場所で停止させる必要があるが。

っつーかもっといい手があるのかどうか俺も知りたい。

922 ：デフォルトの名無しさん：02/11/16 02:33

ＯＫ　埋め立て成功。
　　　　　　　　　　　 ∧＿∧
　　　　　∧＿∧ 　（´<_｀　）
　　　　（　´_ゝ`）　/　　 ⌒i 　　さすがだな兄者。
　　　　／　　　＼　　　　|　|
　　　 /　　　/￣￣￣￣/　|
　＿_(__ﾆつ/　 FIVA　/ .| .|＿＿＿＿
　　　　＼/＿＿＿＿/　（u　⊃

923 ：772：02/11/16 02:54

＃うわあ。見ないでいたらこんな事態に…
＃なんか終息しかけてますけど、まあ話題としては面白いのでいいけど。
ええと、>>788が重要な指摘だと思いますよ。

>>786の「実際には目的のデータであることを確認後」
この確認はどういうコードで行っているのですか？
ぱっと思いつくコードは例えばこうなんですけど。

//目的のデータであることを確認
O3 = O1 ; //ここで既に参照カウントが上がってる！
if (! IsWanted(O3)) {
//O3生成の瞬間にO1が破棄されているとO3に新規データが入っている
//エラー処理
}

O2 = O1 ; //既にO3があるのでO2は要らないけど安全にコピーできる。

なんか私大間違いしてます？

924 ：デフォルトの名無しさん：02/11/16 05:16

しかし良く考えてみると、リスト全体にロックしないと
removeはやっぱり出来ないんじゃないかなー。
単方向リストでも、双方向リストでも、配列+ホールでも…

少なくとも「ｎ番目getする｣という操作は正しく動かないだろう。
「キーｋを持つ要素をgetする」ときも、一部だけロックで出来る？

925 ：デフォルトの名無しさん：02/11/16 05:22

素直にJava使え。

926 ：デフォルトの名無しさん：02/11/16 07:53

なんでこんなくだらん事で話を引っ張ってるの？＞ >>736

927 ：デフォルトの名無しさん：02/11/16 09:06

http://www15.big.or.jp/~kaini/image/img-box/img20021111111348.jpg
まぁこれでも見てﾏﾀｰﾘしる

928 ：デフォルトの名無しさん：02/11/16 12:13

Javaでもコレクションクラスのthread safetyについて考慮してるのは
jdk1.2以降ですな。

929 ：デフォルトの名無しさん：02/11/16 12:28

>>928
thread safety についてというか、1.1 までのコレクションは莫迦でも使えるように
何でもかんでも同期化してただけ。

930 ：デフォルトの名無しさん：02/11/16 12:40

1.4の日本語ヘルプ
>ConcurrentModificationException
>...
>たとえば、あるスレッドが Collection で繰り返し処理を行なっている間に、
>別のスレッドがその Collection を変更することは通常許可されません。

通常ダメなんだとさ。

931 ：デフォルトの名無しさん：02/11/16 13:41

この争いに参加しなかった俺は自制心の持ち主

932 ：デフォルトの名無しさん：02/11/16 14:50

レベル低いだけだろ?(W

933 ：デフォルトの名無しさん：02/11/16 15:06

>>929
じゃあ、いまでもVectorとか使ってるばかには使わせといた方がいいんですか？

934 ：デフォルトの名無しさん：02/11/16 15:42

Javaなら少なくともreference countで悩む必要はないね。

935 ：デフォルトの名無しさん：02/11/16 17:07

>>934
でも、たま～に使いたくなることあるなぁ。。。

936 ：デフォルトの名無しさん：02/11/16 18:35

参照カウンタの使い方程度も分からないバカはJavaがお似合いだね

937 ：デフォルトの名無しさん：02/11/16 22:23

736 はどうしたのよ？
散々人を見下した発言を繰り返した割には、反論できずにだんまりかよ
ヘタレやの、おまえ

938 ：デフォルトの名無しさん：02/11/16 22:31

>>937
もういいよ・・・

939 ：デフォルトの名無しさん：02/11/16 23:57

真理を見通す目を使ってこのスレを覗いてみた。そこに見えたものは・・・

938 名前：736 投稿日：02/11/16 22:31
>>937
もういいよ・・・

940 ：デフォルトの名無しさん：02/11/17 00:04

736マジ死亡!?
もっと踊ってくれよ

941 ：772：02/11/17 00:29

>>923
あ、違った。O1がBスレッドにあるという時点で
既に参照カウントがアガってなきゃいかんのか。
鬱だ…。

DataType O1;
hr = pDataList->GetItem(index, &O1) ;
if (FAILED(hr)) { /* エラー*/ }
if (IsWanted(O1)

とか。ふむ。確かにリスト側で排他したくなるし、
同時に他スレッドで削除されてると面倒。やっと分かった。

942 ：767=793=902=918=921：02/11/17 02:31

>>941
参照を得る/切るタイミングでアトミックにカウントが上がる/下がる必要が
あるからなぁ。
そうでないと、無効なオブジェクトを参照してしまう。

ならば、参照カウントが 0 でも有効な(というより、無効かどうか判別できる)
ものを作るのも一つの手だな。

bool Object::ref(){
　bool valid = false;
　cs_.enter();
　if(refCount_ > 0){
　　refCount_++;
　　valid = true;
　}
　cs_.leave();
　return result;
}

void Object::release(){
　cs_.enter();
　if(refCount_ > 0){
　　refCount_--;
　　if(refCount_ == 0){
　　　garbages__.add(this);
　　}
　}
　cs_leave();
}

で、安全なタイミングで(ってそれが一番むずい気も)garbages__(グローバル変数)
の要素を delete してやると。

943 ：942：02/11/17 02:32

# 続き。改行が多すぎるって言われちまった。

あるいは、Object ではなく、SharedPtr みたいな入れ物でこれをやっても良い。
SharedPtr のフィールドは Object* を格納する ptr_ と refCount_。refCount_ が
0 になったときに delete ptr_ するけど、 SharedPtr 自体は無効な状態で
残り、garbages__ に入る。

コメントくれ 736。もしくは偉い人。

944 ：942：02/11/17 02:40

>>942
ああ。result 返してるよ。ref の最後は return valid; ね。
コンパイルくらいは通すか...

945 ：デフォルトの名無しさん：02/11/17 04:18

もまいら別スレ立ててそっち逝け

946 ：デフォルトの名無しさん：02/11/17 08:10

>>943
736でも偉い人でもないが…

ref()がfalseを返したら、いったい何をすればよいんだ？

そもそも、release()で参照が0になるということは、release()を呼んだスレッド
以外からの参照はないはずなのに、他からref()が呼ばれるのがおかしいってば。

リストのgetとremoveが排他制御をちゃんとやれば、そういうことは起きないだろ？
getがロックを離す前にはrefが済んでいる。あるいは、removeが先なら、
参照が他のスレッドに渡ることはない。

947 ：デフォルトの名無しさん：02/11/17 16:21

やっぱり、どう考えてもリスト全体をロックするより無いなー。

948 ：デフォルトの名無しさん：02/11/17 22:17

Javaを使えば簡単に解決する低次元な問題に
一生悩みつづけるC++プログラマのスレはここですか？

949 ：デフォルトの名無しさん：02/11/17 22:24

二日留守にしてたからとっくに終ってるかと思えば、まだ続いてたのかよ。こ
の736祭は。

950 ：デフォルトの名無しさん：02/11/17 22:31

>>948
>>930

951 ：デフォルトの名無しさん：02/11/17 22:41

>>948
うん
だからオマエには関係ないんよ
どっか逝け、二度と来んな

952 ：942：02/11/17 22:45

>>946
いやだから。
List で排他制御をかけずに安全な方法があるかを探してる。

ってあまりやると今度は俺が煽られるかな。

953 ：デフォルトの名無しさん：02/11/18 00:50

>>952
特殊な場合はあるかもしれんが、一般的なリストのセマンティクスを
ロックなしで一貫性を持って実現するのは無理だろう。

たとえば
「n番目を取り出す｣→他のスレッドが先頭を削除したら、戻ったときには正しくない値を返してしまう。
「データｘを含む最初の要素を取り出す｣→探索中に他のスレッドが先頭にｘを
付け加えたら…

954 ：942：02/11/18 01:19

>>953
その特殊な場合が知りたい。
そのために、902 の List::remove では、items_[index] = NULL をもって
要素削除としてる。

いや、現実問題、こんなことしてたら、List も Object も、使う側に
知識を要求する、やっかいなクラスになるとは思う。

ただ、そうすることによってパフォーマンスが得られるなら、
それが有効な選択肢になる場合もある。
ってことで、無理問答みたいなことを続けてるわけだ。

っていうか 736 が続けてくれよこれ。

955 ：デフォルトの名無しさん：02/11/18 10:58

あのさぁ、参照カウントの時に出てきた↓を見てみたんだけど、
http://www.gotw.ca/gotw/045.htm

void String::AboutToModify(size_t n, bool bMarkUnshareable /* = false */)
　int refs = IntAtomicGet( data_->refs );
　if( refs > 1 && refs != Unshareable ) {
　　StringBuf* newdata = new StringBuf( *data_, n );
　　if( IntAtomicDecrement( data_->refs ) < 1 ) {
　　　delete newdata; // just in case two threads
　　} // are trying this at once
　　else { // now all the real work is
　　　data_ = newdata; // done, so take ownership
　　}
　} else {
　　data_->Reserve( n );
　}
　data_->refs = bMarkUnshareable ? Unshareable : 1;
}

の、delete newdataって間違いじゃない?

956 ：955：02/11/18 11:25

複数のスレッド(それぞれが参照を持つ)が同時にAboutToModifyを呼び出すと、
それぞれが共有を解除して、独自にデータを持つわけだが、その内の一つは
data_->refs が0になるから、元の共有していたdata_の指す先か、newdataの
一方を開放する必要がある。

というのは判るんだけど、AbountToModifyは共有解除と共にsize_t nに
データ領域のサイズを拡張しなきゃならんのに、delete newdataでは
data_の指す先の領域のサイズはsize_t nだけあるとは限らなくない?

ここは、単純に
if( IntAtomicDecrement( data_->refs ) < 1 ) {
　delete data_; // just in case two threads
}
data_ = newdata; // done, so take ownership
じゃないかと思うんだが…

957 ：名無しさん＠カラアゲうまうま：02/11/18 14:10

あるいはこうか?

　　if( IntAtomicDecrement( data_->refs ) < 1 ) {
　　　delete newdata; // just in case two threads
　　data_->Reserve( n );
　　} // are trying this at once

958 ：955：02/11/18 16:22

ですな。
でも、既にnewdataはサイズn以上で領域確保しているので、
data_を破棄する方が良いかと。

誰も、反論が無いところを見ると、やっぱり間違いと言う事でよろしいか?

959 ：デフォルトの名無しさん：02/11/18 16:33

パフォーマンスを得るためならreference count法なんて
使っちゃいかんと思うが...

960 ：名無しさん＠カラアゲうまうま：02/11/18 17:15

>>958
いいんじゃん。

ところで、次スレって立てんの?

961 ：デフォルトの名無しさん：02/11/18 18:59

>959

別にリファレンスカウントでアロケーション回数を少なくしてパフォーマンスを稼ごう
という事ではなくて、そもそも大域的なデータをマルチスレッドで使う時には意味無いかな?

962 ：デフォルトの名無しさん：02/11/19 00:11

>>960
マルチスレッドプログラミングの苦労はすべて、
C++を使う事が原因だと結論が出たので、
次スレは不要でしょう。

963 ：デフォルトの名無しさん：02/11/19 00:58

たてますよー

964 ：963：02/11/19 01:02

載せるようなリンク先がねえよ...

965 ：デフォルトの名無しさん：02/11/19 01:16

>>962
どっちかというと、不要なのはオマエだな

966 ：次スレの逝ってよしの１：02/11/19 01:43

次スレ立てました
http://pc3.2ch.net/test/read.cgi/tech/1037636153/

間違えて３つも立ててしまった・・・
決してマルチスレッドとかけたわけではありませぬ・・・

967 ：デフォルトの名無しさん：02/11/19 02:07

じゃあ1000取りでもはじめるか

968 ：デフォルトの名無しさん：02/11/19 02:07

どれが本スレなんだ・・・。
次スレには全部重複ごめん、次スレはこちら、と書いてあり
リンクをたどると無限ループするんだが・・・。

969 ：デフォルトの名無しさん：02/11/19 02:14

>>968
削除依頼板に書いてあるとおりです

970 ：デフォルトの名無しさん：02/11/19 10:15

スレ立てもマルチスレッドでやって、排他制御に失敗したのはこのスレですか?

971 ：デフォルトの名無しさん：02/11/19 10:20

ここの奴らの話は信用ならねーな

972 ：デフォルトの名無しさん：02/11/19 13:25

つーか「間違えて」3つも立てられるはずないだろ。
明らかに故意に串を差し替えるとか回線を繋ぎ替えるかして
立てたはずだ。
市ねよ。

973 ：デフォルトの名無しさん：02/11/19 13:26

>>968
素朴な参照カウントモデルは循環参照があると
役に立たないのです

974 ：次スレの逝ってよしの１：02/11/19 22:59

>>972
いえ、それが同じアドレスから３連発したのです
一度目はコネクションタイムアウト
二度目は３０秒ぐらいでこちらから停止
三度目で成功
で、気づいたら３つ立ってました（；＿；）
一回目の段階で、しばらく待って、スレ一覧をチェックすればよかったんですね。

しばらくスレ立てはやめときます・・・

975 ：デフォルトの名無しさん：02/11/20 00:28

2ch の調子が悪くてスレ立ての重複が頻発しているらしいよ。

976 ：デフォルトの名無しさん：02/11/20 11:59

>973
> 素朴な参照カウントモデルは循環参照があると

うん、それで？
参照カウントを使って、どんな場合にも使えるクラスを設計しようとしてるならともかく、
循環参照が発生しないデータモデルで使用する場合には、何の意味も無いな。

>972
スレが３つ立ったからって、そんなに迷惑被ったのかヨ？
引きこもりは、攻撃性が強くて困るな。

977 ：デフォルトの名無しさん：02/11/20 12:50

>>976
「リンクをたどると無限ループ」に引っ掛けたネタに
マジレスされても困るのだが

978 ：デフォルトの名無しさん：02/11/20 13:47

>>973
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ
>>976
ﾈﾀﾉｶｲｾﾂｶｺﾜﾙｲ

979 ：デフォルトの名無しさん：02/11/20 13:48

>>978
>>976 -> >>977
ﾈﾀﾉﾃｲｾｲｶｺﾜﾙｲ
ｲｯﾃｷﾏｽ...

980 ：デフォルトの名無しさん：02/11/24 17:19

誰も居ない・・・
？？？？するならイマノウチ

981 ：デフォルトの名無しさん：02/11/24 18:11

？？？？

982 ：デフォルトの名無しさん：02/11/24 20:18

？？？？