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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 17:44 / Filesize : 232 KB / Number-of Response : 919
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:26:16 ]: マルチスレッドプログラミングについて語るスレ

■前スレ
マルチスレッドプログラミング相談室その６
ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/

■過去スレ
その１ ttp://pc3.2ch.net/tech/kako/997/997345868.html
その２ ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/
その３ ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/
その４ ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/
その５ ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/

OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ

【ＯＳ】

【言語】

【実行環境】

【その他突起する事項】
710 名前：デフォルトの名無しさん mailto:sage [2009/09/01(火) 20:34:22 ]: なるよ
711 名前：デフォルトの名無しさん [2009/09/01(火) 20:38:55 ]: >>710
そうっすか！ならよかったです。
712 名前：デフォルトの名無しさん mailto:sage [2009/09/01(火) 21:08:29 ]: erlang
713 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 00:40:31 ]: >>709
MFCには詳しくないけどシングルコアで問題なく動いてたMTセーフのつもりの
プログラムがマルチコアにもってくと異常動作することはそれなりにあるん
じゃないの？int型への代入・参照を非同期でやってたりするプログラムだと。
714 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:07:14 ]: >>713
何故int? 64bit整数ならわからんでもないけど。
715 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:11:11 ]: つーかそんなことを質問してるわけじゃねーし。
言ってみたかっただけだろ。
716 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:18:05 ]: intでもread-modify-writeはatomicじゃないぞx86は（も）
717 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:18:42 ]: >>709
なる。OSネイティブのスレッドは、明示的に指定しない限り、複数のコアに分散される。
とは言え、排他制御が適切でないと、各コアを有効に利用できないけど。
718 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:27:46 ]: >>716
いや、それだったらそもそもデータ型問わんのでは。
719 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:33:30 ]: いやいや、おまいら、それ以前にそれはスレッドセーフと呼ばないのでは。
720 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 02:19:59 ]: >>718
64bitなら、と言ってるから、マシンワードならアトミックと思ってるのかなと思った
721 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 03:38:51 ]: volatile
722 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 06:06:12 ]: volatileがどうかしたか？
723 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 09:42:27 ]: vottakle
724 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:14:01 ]: 明白な答えが、ここで出せるわけ無いんだから。
あなたが欲しいのは同意なんじゃないの？だから荒れる。
725 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:37:33 ]: >>724
独り言が言いたいだけだ、とかでないなら
最低限アンカーくらい書いたら？
726 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:55:09 ]: >>725
ごめんめっちゃ誤爆
727 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:57:38 ]: 　　　　　　　　∧∧
　　　　　　ヽ(･ω･)/　　ｽﾞｺｰ
　　　　　＼(.＼ノ
　　　　､ﾊ,,､　￣
　　　　￣
728 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 14:27:31 ]: >>696
いまひとつ怪しい記事だな。
だいたい今の.NETじゃ前提が変わりすぎてて、役にたたないどころか害のが多い気がするし。
729 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:22:08 ]: >>720
64bitを持ち出したのは、32bitマシン(あるいは32bitモード)だと、単一の書き込み/読み出しでも競合すると値が壊れる可能性があるから。
(最初の32bitが書き込み前の、次の32bitが書き込み後の値を読み出す可能性がある)
マシンワード以下なら、順序が入れ替わることはあっても値が壊れることはないと思ってるんだけど、それもあてにならない?
あと、x86系だと、ワード境界をまたぐ読み書きがどうなるかがよくわからない。
730 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:40:02 ]: P6以降はキャッシュアラインドなマシンワードのreadやwriteはアトミックだよ
read-modify-writeはLOCK#がassertされないとアトミックじゃないよ
xchg命令は昔からLOCK#がassertされる仕様だからアトミックだよ

コンパイラも含めた挙動はこの辺も参考にするといいよ
msdn.microsoft.com/ja-jp/library/bb310595(VS.85).aspx
731 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:48:23 ]: ttp://www.intel.com/Assets/PDF/manual/253668.pdf
ここの 8.1 LOCKED ATOMIC OPERATIONS を嫁
732 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 22:01:55 ]: >>729

>マシンワード以下なら、順序が入れ替わることはあっても値が壊れることはないと思ってるんだけど、それもあてにならない?

w
733 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 00:09:10 ]: The Art of Multiprocessor Programming
糞本だなぁ
734 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 03:59:45 ]: volatile
735 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 05:34:09 ]: volatile変数へのアクセスのアトミック性は、non-volatileな変数へのアクセスと同じ
だから、この流れにvolatileは何の関係も無いよ
736 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 09:27:34 ]: >>706
読み取り側ではメモリバリアはいらないの？
737 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 10:14:24 ]: _Valueの値を読み込む前にその指す先の値を読み込むのは不可能だから
メモリバリアがなくても読み込み順序は入れ替わらないはずで要らない・・・んじゃないかなたぶん
738 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:09:34 ]: >>737
＞_Valueの値を読み込む前にその指す先の値を読み込むのは不可能だから
＞メモリバリアがなくても読み込み順序は入れ替わらないはずで要らない
それが成り立たないアーキテクチャもあるんだな。
www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html
739 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:31:35 ]: volatileの話をするときは、C/C++なのかJava/C#(CLI)なのかをはっきりさせろ。
それぞれのvolatileの意味はまるっきり別なんだからな。
740 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:59:30 ]: そうか、やっぱりだめか
例の記事は今見直したらvolatileが付いてるな
なるほど
741 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 16:18:16 ]: それはメモりバリアかvolatileどっちかって話だから意味ないよ
742 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 16:36:48 ]: そろそろvolatileについて一言いっておくか
ttp://d.hatena.ne.jp/bsdhouse/20090720/1248085754
743 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:04:04 ]: C++っていつまでAtomicIntegerとかないわけ？
ふざけてないか？いい加減にしろ
744 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:06:40 ]: と言われても今年決まる新標準には採用されてるし
一企業や一個人に独占されてる言語と比べるなよ
745 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:10:45 ]: >>744
C++0xは2012年まで延期でしょ
今すごい揉めてるでしょ
746 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:13:31 ]: つーかC++使うならそのくらいはライブラリかAPIか自力で何とかできないと
結局他でつまづく
747 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:23:59 ]: ちょっと来週あたり
C++のatomic実装投下するから誰か100%
厳密に正しいか判断できる人いますか？
748 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 23:38:00 ]: 投下してから聞け。
749 名前：デフォルトの名無しさん mailto:sage [2009/09/04(金) 00:20:53 ]: 現行C++ + Boost + TBBで組んでおけば、C++0xの時代になっても
スムーズに移行できるんじゃないかな
750 名前：デフォルトの名無しさん mailto:sage [2009/09/04(金) 22:04:46 ]: 最近はC++の仕事が減ってC#とCばっかりになったお
751 名前：デフォルトの名無しさん mailto:sage [2009/09/04(金) 23:55:21 ]: blueroad.sakura.ne.jp/entry/20070815.php
752 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 00:54:22 ]: gccだとvolatileは付けても付けなくても
効果ないんだね
753 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 01:06:06 ]: SomeType() = default;

って奴を普通のC++に直すと
どうやってかけばいいの？
754 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 01:11:29 ]: >>753
// SomeType() = default;
755 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 04:53:21 ]: gccでもvolatile付けたら本来のvolatileの効果はあるだろ
756 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 09:45:20 ]: ちゃんと実装されているマルチスレッドアプリってあるのだろうか。
このスレ見てるとある特定の条件下でたまたま運良く動いているアプリばかりじゃないかと思ってしまう
757 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 09:50:07 ]: たまたまでもバグが入り込まなかったのならすばらしいことです
758 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 10:17:49 ]: このスレだけが世界のすべてだと想うなかれ
759 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 10:20:06 ]: 引っ掛かりやすい問題点は多々あるが、ちゃんと分かってくれば安全に書ける
ただ、その「分かってくる」までのハードルがそれなりに高いから、手を出せる開発者
もなかなか増えないし、MTに対応することで恩恵の得られるアプリも少ないから、
MT対応アプリそのものがなかなか増えない訳だが
IntelもMTのフレームワークで金取ってる余裕ねーだろうにと思う（MSあたりは別に
どっちでもいいんだろうが）
760 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:09:19 ]: >>752 は

const volatile int x;

の説明も出来無さそうだな。
761 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:11:26 ]: ああ、const volatileの意味がすんなり理解できるかどうかはいいテストかもなｗ
762 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:50:26 ]: それがconst volatile autoな変数なら私には理解できません。
763 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:13:34 ]: C++0xのautoってcvとか*とか&とか付けられるんだろうか
764 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:27:55 ]: >>760
最適化されないRead Onlyな変数以外に何かの意味があるのか？
765 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:29:06 ]: 別に最適化されない訳でもないが
766 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:29:18 ]: >>758
日本のマルチスレッドプログラム界の縮図がこのスレだと思っておりますが。
767 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:33:20 ]: ここには「実戦ではまだまだ書けませんが」って人もかなりいると思われ
768 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:39:42 ]: >>767
そういうヤツは時間の問題でちゃんと書けるようになる。
そんな自覚のないヤツほどマルチスレッドを使いたがる。
769 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:40:11 ]: 「C/C++の」volatileを誤解してる奴はこれ↓読んどくといいぜ
ttp://mkosaki.blog46.fc2.com/blog-entry-91.html
770 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 13:58:48 ]: マルチスレッドってコンパイラの最適化やCPUの命令の実行順序まで
いちいち気にしていないとまともなプログラムは作れないって事ですか？
771 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:23:36 ]: いいえ
mutexやcondvarの使い方を知っていれば問題ありません
772 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:28:32 ]: mutexは遅いからイヤだ、などと言い出すから話がややこしくなるだけです
773 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:30:03 ]: condvar?
774 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:35:10 ]: 条件変数
win32ならイベントオブジェクトか何か･･････特定の出来事を待って寝ているスレッドを起こすメカニズム
775 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:42:17 ]: スレッド間通信そのものがボトルネックになるような場合は、mutexなんか使って
られないから>>770は真に近い
スレッド間通信のコストが無視できる場合は、>>770は偽に近い
776 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:42:37 ]: >>769
そのブログのおっさんって何者なんですか？
777 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:45:40 ]: スレッド管理APIを作る側なら>>770は真
778 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 16:07:19 ]: >>770
単純に動くものを作りたいなら、そこまでローレイヤーのことを考える必要はない。
が、
プログラムのパフォーマンスを上げたかったりするんだったら、
考える必要が絶対に出てくる。
「まともなプログラム」==「メジャーなソフトウェア」って認識なら、
言う通り、そこまで考えないとまともなプログラムは作れない
779 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 16:08:26 ]: >>770
適当に作ってはったりかます方が金になるから
きちんとモノ作りする奴は馬鹿を見ると思った方がいいぞ
780 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 10:56:31 ]: mutexの速度が気になるようなプログラムなんて組んだことないぜ
速度より安定性重視な俺はプロだって周りかよく言われます
781 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 12:28:25 ]: 必要無いならそれでいい
カーネルやドライバを書いてるような連中はそういう訳にはいかない
科学技術計算やゲームエンジンを書いてるような連中もな
782 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 13:20:16 ]: 正しく動くものできっちり金を取った後、
また高速化するたびにきっちり金を取るのはプロだと思う。
783 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 13:31:25 ]: 最初からある程度高速じゃないと金の取れない業種もあるけどな
784 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 14:14:35 ]: そういうプロが幅を利かせるから日本のIT業界はいつまでたっても土方っていわれるんだろな
785 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 14:18:37 ]: よく知らんけど海外でもそういう手合いはいるんじゃね？
変に胸張って「俺らこそがプロ」みたいな顔をしてるかは別として
Googleみたいなとこのプロはそういう手合いとは思えないしな
786 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 16:34:28 ]: >>780に同意する。

いかにmutexの回数やクリティカルセクションの範囲を減らすかに設計能力を注ぐ。
要は、スレッド間の同期を減らし、スレッドの並列度を上げることが目的。
ただし、(>>770の言う)コンパイラの最適化やCPUの実行順序までは考えない。
(>>782の言う)正しく動くものを作ることを最優先する。

マルチスレッディングと、その最適化には、高度に抽象化された思考能力と設計技術が要求される。
(>>778の言う)ローレイヤのことを気にした(言い換えると、ローレイヤの振舞いを前提にした)
スレッディングのロジックを組むということは、プラットフォーム依存な設計であるということ。
(>>781の例であれば)科学技術計算ならUNIXからWindowsへ、ゲームエンジンならPS3からXBoxへ
移植するたびにロジックの再設計が必要になる。

もしかすると自分が知らないだけで、(意図的に？)そういうローレイヤ前提な設計をして、
移植の度に利益を得るという(>>778,779,781のような)世界があるのかもしれない。
ただ、それは(>>784の言う)土方仕事と呼ばれる日本のIT業界の縮図そのものであると思う。

例外があるとすれば、カーネルの、しかもスレッドスケジューラやmutexそのものを実装する
コアなデベロッパに限る。彼らはハード(CPU)の能力を最大限に生かす基盤を作る人達だから。
787 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:00:35 ]: いや、普通に移植性の高いlock-free queueとか書けるから。
788 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:04:16 ]: ハードリアルタイムやったことないやつって性能無視の安定指向が強いよな
789 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:07:38 ]: マシンパワーの需要と供給の比がカツカツかトントンか余りまくりかで全然違うからな
それを無視して、どれか一つのパラダイムだけで語る奴は問題がある
790 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:08:37 ]: CompareAndSetとか、既に
どの開発環境でもインラインアセンブラ関数
用意されてるから、CPU変わっても大した話
じゃないよ
791 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:24:48 ]: ところでお前らlock-free queue
とか朝飯前なんだよな？

なぁどうなんだ？
792 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:28:54 ]: >>789
ですよねー周りの見えない技術者ほど使えない物はないです
793 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 19:15:48 ]: 物理シミュだと、精度が要るところは安定性重視でそうでないところはピーク性能重視。
マシンパワーの配分はジョブによって違うから動的に。
794 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 21:30:11 ]: >>791
Javaのマルチスレッド本にlock-free queueの実装が載ってたんだが。
「どうやってlock-freeを実現しているのか」は何とか理解できたが、
自分で一から書けるか、と聞かれると胸を張って「No!」と答えるしかない。
795 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 21:32:03 ]: >>791
俺は今書いてる
書いたらここにうｐして

虐めて貰おう
796 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:00:21 ]: 要求条件によって実装も細かく変わるからなぁ、lock-freeは
797 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:08:59 ]: IntelのMathKernelLibraryはやばい
あれこそプロの仕業だ
798 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:28:11 ]: >>781のような世界では
LockFree程度じゃ満足されないぞ。

RCUとかを使ってCasFreeにして、
メモリバリア(バスロック)を減らさないと充分ではないと言われるんだ。
メモリバリアがあると、シングルコアでもバスクロックで数クロックを消費するが
これが他のコアのCASが原因でも起こるわけだからな。
799 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 23:31:17 ]: >>797
MKLは、OpenMP対応しているから勿論OpenMPで並列実行させてもいいのだけれど。
意外なことに、MKLを使ったプロセスを複数同時実行させてもリニアリティが高いのが凄い。
800 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:19:14 ]: >>798
lock-freeが要求によって実装がまちまち、ってのはそういうのも含めたつもり
CASは使わないがメモリモデルや要件的にRCUも不要な場合とか、色々あるからなぁ
801 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:20:34 ]: ロック中に、割込処理みたいなコンテキストスイッチしない人が飛び込んできたら
デッドロックしちゃうけど、一般的にこういうのはどうやって回避する？
802 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:31:35 ]: 飛び込ませないとか
803 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:35:48 ]: 割り込み処理の中で何かをロックするというのはやめようよ
804 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 07:16:58 ]: >>801
longjump
805 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 09:58:24 ]: ロックって他のスレッドをロックしなければコスト低いのな
特定のクラスの関連のない処理を同じロックオブジェクト使ってすげー遅かったのが
処理ごとに別のロックオブジェクト使うようにしたら殆どコストが無くなった

当たり前だよな・・・
806 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 11:44:54 ]: >>805
では聞くが、それは本当にロックする必要があったのか?w
807 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 11:54:40 ]: あるし
808 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 12:56:39 ]: ロックの粒度は可能な限り小さくする派です
でもそれ以前になるべくロックしないでいいように設計します
809 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 15:37:35 ]: それが言いたかったんです
けど小さいロックを連続でするくらいなら少し大きなロックを1回の方が効率いい時もある
810 名前：デフォルトの名無しさん mailto:sage [2009/09/07(月) 15:47:31 ]: 以前ねえ、ロックの粒度を細かくしていったら
滅多に競合しないのに、オブジェクト毎に計数千個のロックが作られる事態になったことがある。
(rwlockのエミュレーションで、Win32でやってみたらHANDLEの使用量が跳ね上がったり)

で、こういう場合はどうするのが妥当？

1) そのまま数千個使う
2) ハッシュ等でロックを減らす
3) がんばってrease-releaseする形にする

まあ3)が一番まともかと思うんだけど
CASとかを使ってうまく解決できるのかな。

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef