5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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()はなんでガードしないと行けないんですか?
4バイトのインクリメントならアセンブラで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の利点の一つのクラスにスレッドを簡単に割り当てられる、
これをどう活用したらいいのか?これにはあんまり参考にならないんだよね。

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

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 :57:01/09/01 00:47 ID:YEBV7iy6
>けど、process内部のthreadからのsignalならば、
>process内の事は自分で管理できるよね?
ふむ、何となくわかった気もする。

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

62 :IDEなんてクソ:01/09/01 01:11 ID:N2P03Y3g
UNIX歴長い人はすぐにシグナル使うけど、
マルチスレッドを使う場合は、極力シグナルを
使わない。素直に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の本はとってもいい本だったYO

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
Σ(゜д゜lll)ガーン  沈み掛けてる

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
やめちまえ!!

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

90 :デフォルトの名無しさん:01/10/10 22:53
才能が無ければ普通はやめた方がいいと思うが
それとも、プログラミングが一番得意だったりして(笑)

91 :デフォルトの名無しさん:01/10/10 23:10
じゃあ、802師匠は大学院生にもなって童貞ですけど男をやめたほうがいいのでしょうか?
それともオナニーが一番得意だったりして(藁)

92 :デフォルトの名無しさん:01/10/12 21:19
板違いかも知れませんが御案内です。
クロスポストですみません。
今、801板で2ちゃんねるの有志が集まった同人ゲームの
開発が進んでいます。
801板住民で本気でボブゲを作るスレッド2
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の獲得を待っているスレッドを停止できる、とは言えないのでは?
例えば、スレッド1がロック1を持ち、スレッド2がロック2を持っていて、
スレッド1がロック2を獲得しようとして、同時にスレッド2がロック1を獲得しようと
する、いわゆるデッドロックの状態で、別のスレッドからスレッド1のstopを呼んでも、
スレッド1は停止(中断)しない。結局、デッドロックは解消しない。
元の問いが、synchronizedで待っているスレッドを中断する、ということだから、これは
stopでもできないというのが正解では?
mutexなどの利用については、その通りだと思うけど。

99 :デフォルトの名無しさん:01/10/14 05:47
定説1:メインスレッドから複数のスレッドを呼んではいけない。
(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

それはもしかして、

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

という類のこと?

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も不具合ありそう。

35 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)