ふらっと C#,C♯,C＃（初心者用） Part138

2018/06/05(火) 19:32:42.28

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■関連スレ
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part137
https://mevius.5ch.net/test/read.cgi/tech/1523004019/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2018/07/19(木) 07:22:53.40

>>696
awaitでは上手く実現できなさそうな構造でした

https://msdn.microsoft.com/ja-jp/library/system.threading.monitor(v=vs.110).aspx
monitorクラスを使って実現できそうだなとなりました
ただこれのシグナルを投げるpulseとpulseallの違いがよくわかりません
pulseは変数で渡したオブジェクトのスレッドを、pulseallは渡すオブジェクトとか関係なくwaitで止まってるすべてのスレッドを動かす？

2018/07/19(木) 07:52:34.10

>>724
>awaitでは上手く実現できなさそうな構造
なぜ？

2018/07/19(木) 07:53:35.73

>>724
つまりProducer-Consumerだろ？
まさにBlockingCollectionのユースケース

2018/07/19(木) 10:16:19.48

Aそのものは非同期(バックグラウンド)で動く必要があるとして
そもそもBが非同期で動く必要性がわからん
かならず応答きてから次をよぶんだろ？

2018/07/19(木) 11:39:51.48

むしろ一番の疑問は、
＞リクエストは一つずつ送らないといけない制約がある

のであれば、キューを持つべきなのはリクエストを送る側ではなく受ける側なんじゃないか、
なぜリクエストを送る側に受ける側の都合に合わせる負担をさせるのか、
ってことだと思うけど、まあ話が曖昧過ぎてよくわからんね。

**719** (ﾜｯﾁｮｲ ff8a-H0hI) · 2018/07/19(木) 12:02:04.85

>>722
自分のコードだと野暮ったくて古い感じがしたんですが
out var　なるものを使ってすっきりさせるんですね

>>723
最近、ラムダ式やLINQを始めたんで↓みたいにメソッドチェーンで繋げたかったんですが
これだとやりすぎなんですねｗ

>> myTable.TryGetValue("Iwate", out var s) ? MessageBox.Show(s) : DialogResult.None; とか
>> (myTable.TryGetValue("Iwate", out var s) ? (Action<string>)(x => MessageBox.Show(x)) : (Action<string>)(_ => {}))();
>> とか書けなくはないけど俺ならこんなの書いてきやがったらコードレビューで突き返す

ありがとうございました

2018/07/19(木) 12:23:58.43

見やすくしたり行数減らす為の機能なのに一文に無理やり詰めたら見づらいだろうしな
LINQ使わなくても
;で終わらせた文を一列にずっと書き続けてたらなんだこいつってなるだろうし

2018/07/19(木) 12:45:19.73

MQ使えよ

2018/07/19(木) 13:14:15.48

varのメリットってなに？

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-6Gsv) · 2018/07/19(木) 14:01:22.48

>>732
定期的にこのスレを荒らすメリットがある。

2018/07/19(木) 14:35:28.55

10年で1スレも消費できないムラダ厨がまた初心者スレで暴れてるのか。

2018/07/19(木) 15:40:49.42

>>728
送る側で待たないと仕事を溜め込んだ受け側が最悪死ぬか無視する様になるぞ。

2018/07/19(木) 16:09:05.04

>>735
意味わかんないよ

キューが満杯ならエンキューできないだけ。
そして、キューが満杯になるような事態が起こるかどうかは、キューを送る側受ける側
どちらが持つかという設計の問題とは何も関係がない。

送り側が持てばそんな事態は起こらない、などとはまったく言えない

2018/07/19(木) 16:13:58.11

共有メモリにFIFO作りたいのでサンプルコードください

2018/07/19(木) 19:27:54.48

>>737
基本的にスレチだな

2018/07/19(木) 20:33:54.32

>>737
マルチ乙

2018/07/19(木) 20:34:49.77

バックグラウンドジョブをメモリに置いて管理するとクラッシュした時につらいのでやめてください

2018/07/19(木) 23:06:52.57

>>736
少なくとも送る側が待てばたまらないし、待たすからには大元まで遡って待たせることが出来る。
受け側で貯めちゃうと、そんなコントロールすらできない。

2018/07/19(木) 23:10:07.57

>>737
MemoryMappedFileクラスで共有メモリを作って、そこにリングバッファを作れば良い。
サンプルコード? と言う名の丸投げは知らんw

2018/07/19(木) 23:16:09.86

>>742
ありがとうございます

2018/07/19(木) 23:24:45.38

>>741
何を言ってんの。
ちゃんと自分の頭で考えて言ってる？

キューの容量が100だとする。
リクエストが100まで溜まってしまうかどうかは、キューをどちらが持つかと関係ないでしょ。

スループットはリクエストの処理能力で決まるんであって、キューをどっちが持つかで決まるんじゃない。
当たり前でしょ。

送る側が待てばたまらない？
それは受ける側がリクエスト拒否したらたまらないと言ってるのと同じ

君の世界じゃ、バケツリレーの余分なバケツの置き場所を送り元におくか送り先に置くかで
バケツの輸送能力（単位時間あたりの送れる水の量）が変わるの？

変わるわけがないでしょ
頼むよマジで

2018/07/20(金) 00:04:31.35

>>721
ありがとうございます

すみません、コンポジションというのはどういう手法なのでしょうか？
調べてはみたのですが解説しているサイトが見つからなくて・・・

2018/07/20(金) 00:15:51.43

>>745
クラスのインスタンスをメンバ変数などに設定して持つ

2018/07/20(金) 00:16:43.45

配置計画
GOFはそちらを優先して説明しているが

2018/07/20(金) 01:07:34.53

持つと待つ
混ざりすぎじゃねぇの?
待つって言いたいんだよね?

2018/07/20(金) 06:49:01.24

きたです
https://i.imgur.com/F20EZn1.jpg

2018/07/20(金) 09:57:40.63

>>748
>>744の文中の持つは持つで間違ってないと思う

2018/07/20(金) 10:43:27.30

>>744
だから、貯め無い様にするには、送る側、更にそこに送る側、更に大元の送る行為を辞めされはいいって話。
わかる？

通信のフローコントロールの話と同じなんだよ？

2018/07/20(金) 10:47:52.01

>>751
まだ言ってるのか。

君の世界では
＞送る側、更にそこに送る側、更に大元の送る行為を辞めされはいいって話

これが可能かどうかはリクエストのキューをどちらが持つかに依存するのか。
キューをリクエストの受け側が持ったらそれは出来ないのか。
意味が分からないよ

何が
＞通信のフローコントロールの話と同じなんだよ？
だw
馬鹿過ぎて笑える

2018/07/20(金) 10:50:07.22

よそでやってくんねーかなクソカス

2018/07/20(金) 10:50:53.38

おまえ、目悪過ぎて呆れるわ。

持つなんて一言も言って無いだろw
待つだw マツ。

キューをどっちが持ってるかなんて話はしてない。

2018/07/20(金) 11:06:39.88

アスペルガーの人はひとつのことしか同時にわからないから
二つ話題があることに気がつかない

その話題は持つであってるよ

2018/07/20(金) 11:16:02.27

>>755
まあ普通は受け取る側に郵便受けが無いと受け取る人はいちいち局留めの郵便を受け取りに行かなきゃならないんだけど、まあ、それはどちらでも機能するからあんまり争点にはならないけどね。

2018/07/20(金) 13:07:56.71

バケツリレーの喩えでもスループットは変わっちゃうんだよな。
受け側に送信側が送信する総量より大きいバッファを持てば、スループットは水の入ったバケツを運ぶ時間に依存するだけで済む。
キューがそれより遅ければバケツを引き渡すために時間が余計にかかるわけだから、スループットは落ちる。
送信側にキューを持ったところで、送信側は送信処理に対して同期的に処理しないだけで済むだけで、そのキューからの送出がどんどん遅れるだろう。受け取ってくれないなら。

2018/07/20(金) 13:54:59.01

>>693,695「スレッドを協調して動かしたいです、制約あるんで」
凡人の回答「○○使えよ」
天才の回答「制約が悪い」

2018/07/20(金) 21:28:53.81

c=(a*a+b*b)
c=System.Math.Sprt(c)
これでcの平方根を出そうとしたのですがSystem.MathにSprtの定義がありませんと出ます
sharedevelopを使っています

2018/07/20(金) 21:32:35.58

SQRT

2018/07/20(金) 21:35:00.80

エディタの不具合だろ
SharpDevelopなどという化石は今すぐアンインストールしてVSかVSCodeを使え

2018/07/20(金) 21:44:14.53

平方根の綴りが違う

2018/07/20(金) 22:17:34.54

square rootだからねぇ

2018/07/21(土) 00:28:32.93

ありがとうございます解決しました

2018/07/21(土) 06:52:38.43

スパート!

2018/07/21(土) 13:53:42.54

>>754
もともと
>キューを持つべきなのはリクエストを送る側ではなく受ける側なんじゃないか、
にたいして
>送る側で待たないと仕事を溜め込んだ受け側が最悪死ぬか無視する様になるぞ。
ってレスしてるのが発端なんだが

どうでもいい良いしよそでやって欲しいけど

2018/07/21(土) 14:14:10.21

話題が一変してんのにわざわざ掘り返すなよw
言ってる事とやってる事が矛盾してんぞw

2018/07/21(土) 15:42:07.60

レスバトルって奴だろ
最後に言及した方が勝ちなんだって
これ見るといつも思うが、こういう馬鹿には自分自身を見る自意識がないのかね

2018/07/21(土) 20:00:10.16

たすけて！
Parallel.ForEachの中でデータグリッドの内容を更新してるんだけど
途中で爆発します
データグリッド全体に✕って出て非表示になる
データグリッドの更新処理はlockで囲ってても競合は起きちゃうものですか？

2018/07/21(土) 20:05:25.49

まず原因を切り分けろ
Parallel.ForEachを外しても爆発するか確認するんだ

2018/07/21(土) 20:07:27.16

>>770
パラレルの外出すと機能するけど
そうすると全処理終わってから一回しか更新されない…😌

2018/07/21(土) 20:08:57.28

>>771
UIはUIスレッドからしか操作出来ない
Parallel.ForEachの処理は別スレッドで実行される

2018/07/21(土) 20:10:43.13

>>771
Action<TLocal> localFinally の引数をとるオーバーロードを使ってみたらどうでしょう？

2018/07/21(土) 20:10:44.76

>>768
君のレスを見るといつも思うが、こういう特徴のある口調のレスを繰り返す人には自分自身を見る自意識がないのかね

2018/07/21(土) 20:10:59.84

invokeするか、ContextにPostするしか無いんじゃないかな

2018/07/21(土) 20:22:09.68

>>774
>>774

2018/07/21(土) 20:22:10.55

爆発w

2018/07/21(土) 20:24:00.77

>>772
>>773
>>775
Invokeでググりました
まさにこの疑問を解決するための機能でした
有難う御座います

2018/07/21(土) 20:35:04.73

私は >>773 ですが Invoke について自分があまり良く分かってない気がしてきたので
詳しい方がいらっしゃったら教えてください

UIスレッドで Parallel.ForEach を呼ぶとUIスレッドをつかんだまま並列処理が実行されて、
その並列処理のスレッドで Invoke を使うとデッドロックしてしまう気がするのですが
実際はそういうことはないのでしょうか？

2018/07/21(土) 20:36:04.76

マルチスレッドにしてInvokeしまくると結局パフォーマンスがガタ落ちしたりするがな

2018/07/21(土) 21:15:58.91

>>779 です
WPF で下のようなコードを実行してみたらやっぱりデッドロックしてしまいました
Invoke はそれなりに慎重に使わないといけないみたいです

void Button_Click(object sender, RoutedEventArgs e)
{
　　MessageBox.Show("このメッセージは必ず表示される");
　　Parallel.ForEach(Enumerable.Repeat(0, 2), i => Dispatcher.Invoke(() => { }));
　　MessageBox.Show("デッドロックするとこのメッセージは表示されない");
}

ちなみに Enumerable.Repeat(0, 2) の部分を変えると以下のような挙動でした

Enumerable.Repeat(0, 0) に変える → デッドロックしない
Enumerable.Repeat(0, 1) に変える → デッドロックする
new int[] { } に変える → デッドロックしない
new int[] { 0 } に変える → デッドロックしない
new int[] { 0, 0 } に変える → デッドロックする

2018/07/21(土) 21:16:52.59

>>778
いいってことよ(´・ω・｀)b

2018/07/21(土) 21:18:17.40

>>779
並列処理はUIスレッドではないスレッドで行われるよ。
いや、UIスレッドで行われるとは限らない、と言う言い方の方が正しいかな。
UIスレッドを掴んだままの意味がわからんが、挙動が謎なら、ブレークポイントつけて実行して、どのスレッドが何をしてるかを把握してはいかがだろうか。
今どのスレッドを使ってるかは表示されてるから。

2018/07/21(土) 21:20:54.98

WPFかあ

2018/07/21(土) 21:25:21.58

Windows版VSCodeで、monoを構文解析用のコンパイラとして指定することってできないのかな？

Unityの.Net4.0用プロジェクトで、数ヶ月前までは、.Net3.5用のSystem.Data.DLLを読み込んでくれたのにさあ
VisualStudioを更新したら構文解析用のコンパイラが変わったのか、古い.net3.5用のDLLを読み込んでくれなくて赤波線だらけになっちゃったぜ
4.0用のDLLもあるわけだけど、それを入れるとUnityのmonoの方でなぜかエラーを起こすし・・・どうしたら良いものか・・・・

2018/07/21(土) 21:33:11.65

>>783-784
レスありがとうございます

> いや、UIスレッドで行われるとは限らない、と言う言い方の方が正しいかな。
>>781 で new int[] { 0 } だとデッドロックしないあたり、まさにそんな感じですね

> WPFかあ
>>769 でデータグリッドと書かれていたので、
今の Windows フォームなら DataGrid ではなく DataGridView かなと思って
WPF の方で試してしまいました（汗
Windows フォームだと挙動が変わるならそれも知っておきたいので
今からそっちでも試してみます

2018/07/21(土) 21:36:50.95

Windows フォームで試してみたのでご報告を。
以下のコードを実行してみた結果、やっぱりデッドロックしてしまいました
Enumerable.Repeat(0, 2) を変えたときの挙動も >>781 と同じでした

void button1_Click(object sender, EventArgs e)
{
　　MessageBox.Show("このメッセージは必ず表示される");
　　Parallel.ForEach(Enumerable.Repeat(0, 2), i => Invoke(new Action(() => { })));
　　MessageBox.Show("デッドロックするとこのメッセージは表示されない");
}

2018/07/21(土) 22:26:34.46

えーわからん…
ちなみにフォームですビューです
つまりフォームアプリでParallel処理内でinvokeってそもそも悪手なんでしょうか
それともThread生成してその中でParallelすれば良かったり…？これはすごい破綻してる気がしますが

uiスレッドから切り離した他スレッドから安全にuiを制御するなんて考えが可笑しいんでしょうか

2018/07/21(土) 22:44:23.68

>>788
あくまで私一人の考えですが・・・

[1] Invoke を使うと >>779 に書いたような理由でデッドロックするので
　Parallel.ForEach でUIスレッドを使いたいなら >>773 のようにすべき
[2] しかし、同じく >>779 に書いたように Parallel.ForEach はUIスレッドを
　つかんだまま並列処理を行うのでデータグリッドの更新処理だけ
　Parallel.ForEach から切り出してもほとんど同じなのでは？
　（一応 localFinally 中も他のスレッドは動けるので
　　　そこで更新処理を行う方がいい場合もあるかもしれない）
[3] 並列処理が必要なほど大きな処理を行うなら、
　一度UIスレッドを手放す選択肢も考えてみては？

ただ、Invoke がダメだと考えている人間自体が私だけのような気もするので
他の方の意見も聞いてみたほうがいいと思います
あと、[3] に関しては場合によりけりだと思うので、
具体的な処理内容を教えていただければ私の考えをお伝えしたいと思います

2018/07/21(土) 22:55:07.29

>>787
そのコードだと、button1_Click()がずっとUIスレッドを握ったまま。
だから、Parallelの別スレッドでInvoke()しようとしてもUIスレッドに遷移出来なくて固まる。

2018/07/21(土) 23:00:46.86

既に>>779に書いてあったね。その通り。

2018/07/21(土) 23:10:20.56

>>790-791
レスありがとうございます
>>779 の考えで正しいのか不安だったのですがお陰様で自身が持てました
他に何かおかしなことを言ってしまっていたら教えていただけると嬉しいです

>>788
>>789 はレスとしてとっ散らかっている気がしてきたので一問一答で答えてみます

> つまりフォームアプリでParallel処理内でinvokeってそもそも悪手なんでしょうか
Parallel を UI スレッドで実行する場合は悪手というか、致命的だと思います

> それともThread生成してその中でParallelすれば良かったり…？これはすごい破綻してる気がしますが
それなら期待通りの動作にはなると思います。ただ、確かにあまりいい方法ではないと思います

> uiスレッドから切り離した他スレッドから安全にuiを制御するなんて考えが可笑しいんでしょうか
正しく Invoke を使えば問題ないと思います
しかし今回の件からもわかるように、Invoke を正しく使うのはなかなか難しいようです

2018/07/21(土) 23:21:21.79

.Invokeではなく.BeginInvokeを使うのはどう？

2018/07/21(土) 23:30:54.97

>>793
それって
> それともThread生成してその中でParallelすれば良かったり…？
よりも更にワチャワチャする気がするのですがどうなんでしょう？

ワチャワチャって具体的にどういうことなのか
説明を求められれば頑張ってみようと思いますが、
自分の考えがあっているかも、それをうまく説明できるかどうかも
自信がないので、詳しい方の意見を聞けると嬉しいです

2018/07/21(土) 23:41:01.32

>>794
そんな難しい話じゃないっすよw

BeginInvokeは非同期に実行される、つまりキューにデリゲートを入れたらすぐに処理を返すので
Invokeのように自分で自分の終了を待機する状態に陥らない

2018/07/21(土) 23:43:41.94

>>792
有難う御座います
これで行けたので実装試してみます

void button1_Click(object sender, EventArgs e)
{
　　MessageBox.Show("このメッセージは必ず表示される");
　　Task.Factory.StartNew(() =>
　　{
　　Parallel.ForEach(Enumerable.Repeat(0, 2), i => Invoke(new Action(() => { })));
　　}
　　MessageBox.Show("デッドロックするとこのメッセージは表示されない");
}

2018/07/21(土) 23:55:52.12

>>795
レスありがとうございます
おっしゃる通りBeginInvokeはキューにデリゲートを入れたらすぐに処理を返すので
次から次へとキューが入って大変なことになりそう・・・と思ったのですが、
そんなに心配することではないのでしょうか

>>796
それで一応動くと思いますが、Parallel.ForEach が終わる前に
二つ目の MessageBox.Show の行に移るので注意してください
・・・というか、localFinally を使ったり更新処理だけを切り出したりはダメっぽいですか？
ダメだと考えられた理由を教えていただければ何かアイディアを提供できるかもしれません

2018/07/22(日) 00:03:07.23

>>797
データグリッドビューは進捗状況を見るために更新していて
1行1スレッドで処理されて処理後にどう処理されたかをリアルタイム表示してます

ダメではなく単純に自分が分かってないだけです
この処理ならlocalFinallyが最適かもです
深く調べてみます

2018/07/22(日) 00:13:38.17

>>798
> データグリッドビューは進捗状況を見るために更新していて
> 1行1スレッドで処理されて処理後にどう処理されたかをリアルタイム表示してます
進捗状況の確認が必要なほど1行あたりの処理に時間がかかる理由は何でしょうか？
もしその理由が IO など、CPU 以外のところにあるのだとすれば、
Parallel.ForEach を使うこと自体を見直したほうがいいかもしれません

> この処理ならlocalFinallyが最適かもです
正直なところ、更新処理だけ切り出す方法よりも localFinally の方が
適切なケースはまれだと思います
ただ、localFinally の使い方がわかれば更新処理を Parallel.ForEach の外に
切り出す方法もわかると思うので、とりあえず調べてみて損はないと思います

2018/07/22(日) 00:23:24.78

>>799
圧縮ファイルを解凍して中のファイルを加工して再び圧縮し直す
これで1タスクです
1ファイル200MBほどで100ファイル以上処理することが多いです
圧縮解凍、加工は外部ツールを使用しててProcessStartInfoで処理されます

2018/07/22(日) 00:35:58.51

>>800
なるほど～
CPU 処理も IO もあって微妙なところですね

ちなみにその外部ツールはマルチスレッドを使うオプションはないでしょうか？
（例えば 7-zip.exe だと -mmt がそれにあたります）
もし外部ツールがマルチスレッドに対応してるなら、
並列処理はそっちに任せてしまうというのはどうでしょう？

または、外部ツールではなく SharpCompress のようなライブラリを使うことができれば、
C# によるより細かい制御も可能になると思います

2018/07/22(日) 00:37:18.94

汎用的なものとは思えないし、動けばどうでもいいだろ
俺ならそういうのはいちいちGUI付けずにコンソールでやっちゃうな

2018/07/22(日) 00:45:55.06

>>800
それともう一つ、外部ツールを呼び出すのにデフォルトの ParallelOptions で
Parallel.ForEach を呼び出すのはさすがにまずいと思います
ParallelOptions 自体に MaxDegreeOfParallelism というプロパティがありますし、
ParallelOptions の TaskScheduler プロパティに以下のような自前のスケジューラーを
設定すればより柔軟な並列処理を実現できると思います

同時実行の程度を制限するタスクスケジューラを作成する
https://msdn.microsoft.com/ja-jp/library/ee789351(v=vs.100).aspx

>>802
それは確かにｗ
完成したソフトによって得られる利益よりソフトを作るコストのほうが大きくなってしまったら
意味がないですからね
（ただしソフトによって得られる利益には開発者のスキルアップも含まれる・・・と言ってみたりｗ）

2018/07/22(日) 00:48:52.21

>>801
7zip使ってます
スレチになるけど
mmtは一つの処理をマルチに実行するものではないでしょうか

圧縮形式は決まってなく複数あるので7zipを使用してます
zip rar lzh以外にも色々

2018/07/22(日) 00:51:33.52

>>803
タスクスケジューラー調べてみます良さそうですね

i7使用しててMaxDegreeOfParallelismは常に8で実行してます
8スレッドで画面カッチカチで処理してます
暴力です

2018/07/22(日) 00:54:31.49

>>804
> mmtは一つの処理をマルチに実行するものではないでしょうか
その通りです
したいことが「進捗状況を表示できるようにすること」と「並列化により処理時間を短縮すること」
だとすれば、それで問題ない（というかむしろその方が望ましい）の思うのですがいかがでしょうか？

2018/07/22(日) 00:59:41.83

>>805
MaxDegreeOfParallelism を使ってらっしゃるなら
とりあえず致命的にまずいことはないと思います
ただ、CPU だけじゃなく、同時に8つのファイルの読み書きを
求められる HDD さんの気持ちも考えてあげて・・・ｗ

2018/07/22(日) 01:01:31.55

>>806
後続の加工処理もありエラー監視も含むので進捗知りたいです

2018/07/22(日) 01:03:03.89

>>798
localFinallyよりasync/awaitの方が分かりやすいと思う。

private async void button1_Click( object sender, EventArgs e )
{
MessageBox.Show( "このメッセージは必ず表示される" );
await Task.Run( () =>
{
Parallel.ForEach( Enumerable.Repeat( 0, 2 ), i => Invoke( new Action( () => { } ) ) );
} );
MessageBox.Show( "デッドロックするとこのメッセージは表示されない" );
}

2018/07/22(日) 01:04:00.97

makefile使えば？
数行のMakefile書いて make -j8 するだけだよ

2018/07/22(日) 01:04:22.38

>>807
解答先は8GBのRamディスクです
メモリに物理ファイルおいてでここで加工して再圧縮してその後HDDに移動させてます

2018/07/22(日) 01:18:41.37

>>808
Parallel.ForEach を使わなくてもそれはできると思うのですがいかがでしょうか？

>>809
確かにおっしゃる通りですね
後は好みの問題ですが、やはり私は1行ごとに Invoke するよりも
パフォーマンス的に有利な localFinally や更新処理の切り出しを推したいですｗ

>>811
なるほど！そうすれば外部ツールを使っても HDD へのアクセスだけ別に処理できますね
ただ、HDD へのアクセスを別にしようという意識をお持ちで、それだけのスキルもあるのなら、
外部ツールにこだわる必要はないのでは・・・という気もします
あと、メモリは HDD よりはずっと速いですが、CPU キャッシュとかの関係でやっぱり
8 個のファイルを同時に読み出すよりは1つずつの方が良いような気がします

2018/07/22(日) 01:27:28.49

>>809 >>812
いや、でも進捗状況を表示するとなると結局どこかで await は使うことになりそうですね
ただ私としては >>800 のような処理なら Parallel.ForEach は必要ないと考えていて、

foreach (ファイルのループ)
{
　　foreach (進捗状況のループ)
　　{
　　　　await (進捗状況の更新待ち);
　　　　(進捗状況を画面に反映);
　　}
　　(1ファイルの完了を画面に反映);
}

のような感じで十分だと思うのですが、どんなもんでしょうか？

2018/07/22(日) 01:35:51.92

そんな処理速度気にするなら複数PC用意できたりしないのかな？
たぶん内製ツールだと思うけど、そういうのって長期保守とかしないならシンプルでさくっとやれる方向を模索したほうがいい気が…
研究開発兼ねてとかだったらいいんだけど

2018/07/22(日) 01:43:37.75

>>812
そうです、最も投げやすく勝手にマルチしてくれる便利なParallelさんって聞いて使ってるます
別の手段があればコレに拘ることはないと思ってます

>>813
cpuキャッシュとか考慮せずマルチ=高速って誤認識で走ってきて
その中で最適化してきたので
localfinally使用したときと
1ファイルの処理の差も検証してみたいと思います

>>814
ただの趣味なんですPC一台で
複雑でも効果があれば試したいと考えています

2018/07/22(日) 01:44:34.84

ほな寝ます。詳しくありがとうございました！
もしかしたら明日もっとやべーかもです

2018/07/22(日) 01:59:21.48

var block = new ActionBlock<ZipOpParam>(
async (param) => {
await ExecuteZipOpAsync(param);
InvokeUpdateUi(param);
},
new ExecutionDataflowBlockOptions {
MaxDegreeOfParallelism = 8
});

foreach(var p in zipOpParams)
block.Post(p);

block.Complete();
await block.Completion;

2018/07/22(日) 03:07:13.11

>>815
> そうです、最も投げやすく勝手にマルチしてくれる便利なParallelさんって聞いて使ってるます
これは私も同じように認識しています

> cpuキャッシュとか考慮せずマルチ=高速って誤認識で走ってきて
これは場合によりけりだと思います
特に今回のように外部ツール側でマルチスレッドにできる場合はツールの呼び出し側では
余計なことをせず外部ツールに任せたほうが高速になる場合が多いと思います

>>817
C# で並列処理を行うならこれは一つの解決策になりそうですね
別の解決策として、新たに参照を追加する必要のない↓の方法とかどうでしょう？

var tasks = new List<Task>();
foreach (var param in zipOpParams)
{
　　if (tasks.Count == 8) tasks.Remove(await Task.WhenAny(tasks));
　　tasks.Add(ExecuteZipOpAsync(param).ContinueWith(
　　　　_ => InvokeUpdateUi(param),
　　　　TaskScheduler.FromCurrentSynchronizationContext()));
}
await Task.WhenAll(tasks);

2018/07/22(日) 09:28:10.63

違うexeキックすれば終わりなんやで？

2018/07/22(日) 13:48:56.26

オブジェクト指向について勉強しようと思い、クラスを複数作って実行しようとしたら実行ボタンがプロセスにアタッチというよく分からない物に代わりビルドなども出来なくなってしまいました
どうしたら元に戻せるでしょうか

2018/07/22(日) 15:37:48.37

参考にした資料がそう(実行ボタンをプロセスにアタッチ)しろと書いているなら
その手法でトラブった時の解決法も資料に書いてあるのでは

提示されたくらいの情報でここで帰ってくる答えは
「ゴミは捨てて作り直せ」
「一旦オブジェクト指向についての記憶を消せ」
だと思う

2018/07/22(日) 19:34:11.94

このように実行ボタンがアタッチ…となりビルドも行えなくなってしまっています…
プログラムは「確かな力が身に付くc#超入門」から取っていて特にプロセスにアタッチに関する記述も無いので恐らく設定どこか変に弄ってしまったのかと思うのですが…
https://i.imgur.com/QK8r2yI.jpg

2018/07/22(日) 19:59:19.28

>>822
ソリューションエクスプローラーで当該プロジェクトを右クリック→スタートアッププロジェクトに設定（みたいなやつ）を選択