C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[6]: C# 並列処理について


(過去ログ 116 を表示中)

[トピック内 14 記事 (1 - 14 表示)]  << 0 >>

■68409 / inTopicNo.1)  C# 並列処理について
  
□投稿者/ のぶ (34回)-(2013/10/19(Sat) 16:15:31)

分類:[C#] 

C#で並列処理を行おうと思い見よう見まねで以下の様なコードを書いてみました。
目的の動作はできていそうなのですが、この書き方がベストな書き方かが分からないので
添削というか、おかしそうな所等を指摘して頂けるとありがたいと思います。

参考にしたサイト : http://www.kanazawa-net.ne.jp/~pmansato/parallel/parallel_ui.htm
目的             : 対象ファイルに対し処理を行い、その進捗状況をプログレスバーに表示したい(ソースは確認の為TextBoxも使ってます)
button1          : 以下の処理を行う「Run」ボタン
button2          : キャンセルする為の「Cancel」ボタン
button2実装      : button2.Click += (obj, e) => { cts.Cancel(); };

void button1_Click(object sender, EventArgs e)
{
  button1.Enabled = false; //ボタンの無効化
  progressBar1.Value = 0;
  progressBar1.Minimum = 0;
  cts = new CancellationTokenSource(); //Taskキャンセル用
  ParallelOptions po = new ParallelOptions(); //Parallelキャンセル用
  po.CancellationToken = cts.Token; //Tokenの統一

  //対象フォルダの取得
  var dirs = Directory.GetDirectories(@"D:\Test", "*", SearchOption.AllDirectories);

  //対象ファイル(txt)のあるフォルダの取得
  var target = from x in dirs
                where Directory.GetFiles(x, "*.txt").Length > 0
                select x;

  //プログレスバーの設定
  progressBar1.Maximum = target.Count();

  //UIスレッドのタスクスケジューラーを取得
  var tskSch = TaskScheduler.FromCurrentSynchronizationContext();
      
  //taskの実行
  var task = Task.Factory.StartNew(() =>
    {
      try
      {
        //並列処理の実行
        Parallel.ForEach(target, po, path =>
          {
            Thread.Sleep(5000); //ここで実際には対象ファイルに対して処理を行う
            //UI操作用のTaskの実行
            Task.Factory.StartNew(() =>
              {
                progressBar1.Value++;
                textBox1.Text += path + Environment.NewLine;
              }, cts.Token, TaskCreationOptions.AttachedToParent, tskSch);
          });
      }
      catch (OperationCanceledException ex)
      {
        //キャンセルされた場合に例外が発生する
        MessageBox.Show("きゃんせる!");
      }
    },cts.Token);

  //続いて行いたい処理
  task.ContinueWith(arg =>
    {
      button1.Enabled = true;
    }, tskSch);
}

引用返信 編集キー/
■68443 / inTopicNo.2)  Re[1]: C# 並列処理について
□投稿者/ とっちゃん (158回)-(2013/10/21(Mon) 15:12:08)
とっちゃん さんの Web サイト
No68409 (のぶ さん) に返信
> C#で並列処理を行おうと思い見よう見まねで以下の様なコードを書いてみました。
> 目的の動作はできていそうなのですが、この書き方がベストな書き方かが分からないので
> 添削というか、おかしそうな所等を指摘して頂けるとありがたいと思います。

このコードは、実際のモノとは異なるようですが、目的の動作はできているのでしょうか?
目的の動作の本質部分と思われる箇所は、Sleepとなっていますし、「できていそう」ということですので
掲載コードは、ベストどころか及第点すら出せないと言わざるを得ないものです。

それと、最適か?という問いには、必ず○○の時点であれば。。。という条件が付きます。
ですので、最低でも開発環境や、実行環境は提示しましょう。

開発環境が VS2010 なのか、2012 あるいは 2013 なのかではおのずと提示されるコードも変わってきます。

おそらく、このコードなら、async/await でコーディングしたほうがすっきりしたコードになると思います。
実処理部分は、Dataflowなどを利用するほうがよいかもしれません。

また、求めるベストかどうかはわかりませんが
「可読性が高く、実装意図を知らない人が見てもわかりやすいコードであること」
もベストな回答の一つです。

もちろん、どんなに可読性が高く、見目麗しいコードであっても、利用者が満足できる速度で動かなければ意味がありません。


並列処理は、現在のパソコン環境の中では最もホットなロジックの一つです。
(CPUがマルチコア化を進めているため、同時に多数の処理を実行できるようにしないと
CPUパワーの恩恵にあずかれなくなったため)。

そのため、言語レベルでもコンパイラのバージョンなどによって実現方法が大きく変わっています。

並列処理は、C#の中では現在進行形でどんどん進化している項目の一つです。
task がある時点で、VS2010以上(.NET Framework 4以上)であることは判断できます。
ですが、async/await を使っていない(とはいえ、使えないコードとも思えない)ので
VS2012以上かどうかは判断できません(4 でビルドできるソースは4.5でもビルドできる(逆はその限りではない))。

その開発環境と実行環境でベストと判断できるものが変わります。
もちろん、私を含め誰か個人がこれがベスト!と思っていてもそれよりも良いコードが存在することもあります。

おっと。。。肝心の添削。

//対象フォルダの取得
//対象ファイル(txt)のあるフォルダの取得
の2か所。ここをメインスレッドで処理しています
せっかくタスクを起こしているのですから、ここもUIスレッドから外に出して処理しましょう。

でも、どうすればいいかは、目的がわからないので、わかりません。

引用返信 編集キー/
■68449 / inTopicNo.3)  Re[2]: C# 並列処理について
□投稿者/ Jitta (81回)-(2013/10/21(Mon) 22:49:19)
Jitta さんの Web サイト
No68443 (とっちゃん さん) に追加
> また、求めるベストかどうかはわかりませんが
> 「可読性が高く、実装意図を知らない人が見てもわかりやすいコードであること」
> もベストな回答の一つです。

この、「実装意図を知らない人が見ても」というのは、仕事でしているなら、とても重要です。
趣味であっても、半年後の自分はほとんど「実装意図を知らない人」です。
「なぜ、こう書いたか」というところを、ドキュメントに残しましょう。
そうすると、理解できないコードは理解できるまで使わない、ということも選択肢に上るはず。

引用返信 編集キー/
■68449 / inTopicNo.4)  Re[2]: C# 並列処理について
□投稿者/ Jitta (81回)-(2013/10/21(Mon) 22:49:19)
Jitta さんの Web サイト
No68443 (とっちゃん さん) に追加
> また、求めるベストかどうかはわかりませんが
> 「可読性が高く、実装意図を知らない人が見てもわかりやすいコードであること」
> もベストな回答の一つです。

この、「実装意図を知らない人が見ても」というのは、仕事でしているなら、とても重要です。
趣味であっても、半年後の自分はほとんど「実装意図を知らない人」です。
「なぜ、こう書いたか」というところを、ドキュメントに残しましょう。
そうすると、理解できないコードは理解できるまで使わない、ということも選択肢に上るはず。

引用返信 編集キー/
■68458 / inTopicNo.5)  Re[3]: C# 並列処理について
□投稿者/ のぶ (35回)-(2013/10/22(Tue) 09:42:36)
お返事遅くなり大変申し訳ありません。

No68443 (とっちゃん さん) に追加
開発環境の記載漏れ大変失礼しました。
開発環境としては、Win7 + VS2010です。
実行環境もWin7になります。

async/awaitも考えたのですが、まずVS2012をインストールしていないので今回は見送りました。
(VS2010でも.NET 4.5以上は扱えたりするのでしょうか?)

実際の処理を書きますと、
対象ファイルを「ユーザー用フォルダ - updateフォルダ」を共に作成し、そこに移動する。
そして、updateフォルダと同じ場所にiniファイルを作成する。

という事を目的としたプログラムになります。
Sleepの箇所でCreateUpdate(string path)というようなメソッドを呼ぼうかと考えています。

一応自分の中ではコンクリフトはしないと考えたのでそれなら並列処理を行い、少しでも処理を早く終わらせようと思い
先のコードになりました。

> もちろん、私を含め誰か個人がこれがベスト!と思っていてもそれよりも良いコードが存在することもあります。
確かにその通りです。
でも今回参考としたのが、私にとって理解しやすそう・転用できそうという基準で選んだので
果たしてそれがベストな方面なのか、それともスットンキョンな方面なのか判断できなかったので
今回の質問となりました。

# 以上で添削前までの部分に答えたつもりですが、足りないようでしたらすみません


> おっと。。。肝心の添削。

> //対象フォルダの取得
> //対象ファイル(txt)のあるフォルダの取得
> の2か所。ここをメインスレッドで処理しています
> せっかくタスクを起こしているのですから、ここもUIスレッドから外に出して処理しましょう。

UIスレッドから出して処理するとなると、プログレスバーの最大値を設定したいので
Prallel.Foreachの直前にもうひとつtskSchを使ってTask.Factory.StartNewを書き足せばいいのでしょうか?
# 返信ついでに考えた事を書いてますので、後程試します。
引用返信 編集キー/
■68458 / inTopicNo.6)  Re[3]: C# 並列処理について
□投稿者/ のぶ (35回)-(2013/10/22(Tue) 09:42:36)
お返事遅くなり大変申し訳ありません。

No68443 (とっちゃん さん) に追加
開発環境の記載漏れ大変失礼しました。
開発環境としては、Win7 + VS2010です。
実行環境もWin7になります。

async/awaitも考えたのですが、まずVS2012をインストールしていないので今回は見送りました。
(VS2010でも.NET 4.5以上は扱えたりするのでしょうか?)

実際の処理を書きますと、
対象ファイルを「ユーザー用フォルダ - updateフォルダ」を共に作成し、そこに移動する。
そして、updateフォルダと同じ場所にiniファイルを作成する。

という事を目的としたプログラムになります。
Sleepの箇所でCreateUpdate(string path)というようなメソッドを呼ぼうかと考えています。

一応自分の中ではコンクリフトはしないと考えたのでそれなら並列処理を行い、少しでも処理を早く終わらせようと思い
先のコードになりました。

> もちろん、私を含め誰か個人がこれがベスト!と思っていてもそれよりも良いコードが存在することもあります。
確かにその通りです。
でも今回参考としたのが、私にとって理解しやすそう・転用できそうという基準で選んだので
果たしてそれがベストな方面なのか、それともスットンキョンな方面なのか判断できなかったので
今回の質問となりました。

# 以上で添削前までの部分に答えたつもりですが、足りないようでしたらすみません


> おっと。。。肝心の添削。

> //対象フォルダの取得
> //対象ファイル(txt)のあるフォルダの取得
> の2か所。ここをメインスレッドで処理しています
> せっかくタスクを起こしているのですから、ここもUIスレッドから外に出して処理しましょう。

UIスレッドから出して処理するとなると、プログレスバーの最大値を設定したいので
Prallel.Foreachの直前にもうひとつtskSchを使ってTask.Factory.StartNewを書き足せばいいのでしょうか?
# 返信ついでに考えた事を書いてますので、後程試します。
引用返信 編集キー/
■68460 / inTopicNo.7)  Re[3]: C# 並列処理について
□投稿者/ のぶ (36回)-(2013/10/22(Tue) 10:05:02)
返信遅くなり大変申し訳ありません。

No68449 (Jitta さん) に返信
> ■No68443 (とっちゃん さん) に追加
>>また、求めるベストかどうかはわかりませんが
>>「可読性が高く、実装意図を知らない人が見てもわかりやすいコードであること」
>>もベストな回答の一つです。
>
> この、「実装意図を知らない人が見ても」というのは、仕事でしているなら、とても重要です。
> 趣味であっても、半年後の自分はほとんど「実装意図を知らない人」です。
> 「なぜ、こう書いたか」というところを、ドキュメントに残しましょう。
> そうすると、理解できないコードは理解できるまで使わない、ということも選択肢に上るはず。

補足ありがとうございます。
ドキュメントは必ず残します。
現状、ドキュメント類の一切ないプロジェクトの保守を行っているのですが、
死にかけていますので・・・
(むしろ、歴代の開発者たちは素晴らしい能力者達だったのでしょう。関数のコメントすらないC++のプロジェクトなので・・・)



# 以下愚痴といつも思う疑問ですのでスルーして頂いても構いません。
# 現在社内に主立って開発を行える人がいないので、ネットに頼らざるを得ないのですが、
# それが本当に正しいのか判断できないのです。(正しいはニュアンスでとらえて下さい)
# そこでこちらをよく利用させて頂いているのですが、皆様はどうやって学習してきのでしょうか?
# たとえばMVVMの方(面識ないので直接の名称は避けてます)ですとか、ご回答いただいたとっちゃんさんもWixについて深い見識お持ちのようですし。
# お二方ともそれぞれ日本における情報発信源の第一人者と認識していますが、どのようにしているのでしょうか??
# やっぱり海外フォーラムとかから情報仕入れているのかな・・・
引用返信 編集キー/
■68460 / inTopicNo.8)  Re[3]: C# 並列処理について
□投稿者/ のぶ (36回)-(2013/10/22(Tue) 10:05:02)
返信遅くなり大変申し訳ありません。

No68449 (Jitta さん) に返信
> ■No68443 (とっちゃん さん) に追加
>>また、求めるベストかどうかはわかりませんが
>>「可読性が高く、実装意図を知らない人が見てもわかりやすいコードであること」
>>もベストな回答の一つです。
>
> この、「実装意図を知らない人が見ても」というのは、仕事でしているなら、とても重要です。
> 趣味であっても、半年後の自分はほとんど「実装意図を知らない人」です。
> 「なぜ、こう書いたか」というところを、ドキュメントに残しましょう。
> そうすると、理解できないコードは理解できるまで使わない、ということも選択肢に上るはず。

補足ありがとうございます。
ドキュメントは必ず残します。
現状、ドキュメント類の一切ないプロジェクトの保守を行っているのですが、
死にかけていますので・・・
(むしろ、歴代の開発者たちは素晴らしい能力者達だったのでしょう。関数のコメントすらないC++のプロジェクトなので・・・)



# 以下愚痴といつも思う疑問ですのでスルーして頂いても構いません。
# 現在社内に主立って開発を行える人がいないので、ネットに頼らざるを得ないのですが、
# それが本当に正しいのか判断できないのです。(正しいはニュアンスでとらえて下さい)
# そこでこちらをよく利用させて頂いているのですが、皆様はどうやって学習してきのでしょうか?
# たとえばMVVMの方(面識ないので直接の名称は避けてます)ですとか、ご回答いただいたとっちゃんさんもWixについて深い見識お持ちのようですし。
# お二方ともそれぞれ日本における情報発信源の第一人者と認識していますが、どのようにしているのでしょうか??
# やっぱり海外フォーラムとかから情報仕入れているのかな・・・
引用返信 編集キー/
■68467 / inTopicNo.9)  Re[4]: C# 並列処理について
□投稿者/ とっちゃん (159回)-(2013/10/22(Tue) 12:11:01)
とっちゃん さんの Web サイト
No68458 (のぶ さん) に返信
> お返事遅くなり大変申し訳ありません。
>
全然遅くないですよ。
むしろネット(掲示板以外も含め)に、リアルタイム性を求めるほうが無理があります。

> async/awaitも考えたのですが、まずVS2012をインストールしていないので今回は見送りました。
> (VS2010でも.NET 4.5以上は扱えたりするのでしょうか?)
>
.NET 4.5 を利用する場合は、VS2012 あるいはつい先日RTMしたばかりの VS2013(こちらは、4.5.1も利用可能)となります。
今後を考えると、早い段階で 2013 に移行してしまうほうがいいかもしれませんね。

セットアッププロジェクトを利用していない場合は。。。となりますが。


> 実際の処理を書きますと、
> 対象ファイルを「ユーザー用フォルダ - updateフォルダ」を共に作成し、そこに移動する。
> そして、updateフォルダと同じ場所にiniファイルを作成する。
>
> という事を目的としたプログラムになります。
> Sleepの箇所でCreateUpdate(string path)というようなメソッドを呼ぼうかと考えています。
>
この部分は、基本的にファイルの移動(若しくは、別ドライブにコピーしてオリジナルを削除)とINIファイルに書き込みということでしょうか。
だとすると、ストレージ(ディスク)アクセスが中心となります。
INIファイルを作成というのは、ファイルごとに一つではなく、そのフォルダに一つのINIファイルを作成しそこにファイル情報を記述ですよね?

> 一応自分の中ではコンクリフトはしないと考えたのでそれなら並列処理を行い、少しでも処理を早く終わらせようと思い
> 先のコードになりました。
>
考え方としては間違っていません。が、思いっきり競合してます。

まず、ファイルを移動の部分。
移動先はともかくとして少なくとも移動元は同一ドライブです。
とすると、ファイル操作はある瞬間には1つのものに対してしか行えません(ハードウェア的な問題)。
マシン全体で。。。です。

ですので、複数のタスクを同時に動かしてファイルアクセスを行うと、プログラムからのファイル自身の操作は何の支障もなく行えるものの
それを支えるハードウェア上の処理で順次処理となってしまい、並列化の恩恵にあずかれません。

INIファイルですが、こちらは移動先で単一ですか?
もしそうだとすると、同時に複数の書き込みを行おうと思うと競合します。

>>もちろん、私を含め誰か個人がこれがベスト!と思っていてもそれよりも良いコードが存在することもあります。
> 確かにその通りです。
> でも今回参考としたのが、私にとって理解しやすそう・転用できそうという基準で選んだので
> 果たしてそれがベストな方面なのか、それともスットンキョンな方面なのか判断できなかったので
> 今回の質問となりました。
>
> # 以上で添削前までの部分に答えたつもりですが、足りないようでしたらすみません
>
十分足りてますよ。

>
>>おっと。。。肝心の添削。
>
>>//対象フォルダの取得
>>//対象ファイル(txt)のあるフォルダの取得
>>の2か所。ここをメインスレッドで処理しています
>>せっかくタスクを起こしているのですから、ここもUIスレッドから外に出して処理しましょう。
>
> UIスレッドから出して処理するとなると、プログレスバーの最大値を設定したいので
> Prallel.Foreachの直前にもうひとつtskSchを使ってTask.Factory.StartNewを書き足せばいいのでしょうか?
> # 返信ついでに考えた事を書いてますので、後程試します。

ここの回答は、Parallel.ForEach の中身に答えのヒントがありますね。

それと、スケジューラオブジェクトは使い捨てではありません。
スケジューラについては

var tskSch = TaskScheduler.FromCurrentSynchronizationContext();

var task1 = Task.Factory.StartNew(() => { 非同期に処理(); }, cts.Token );
task1.ContinueWith(arg =>{ 非同期処理が終わったらメインスレッドで処理(); }, tskSch);
var task2 = Task.Factory.StartNew(() => { 別の非同期処理(); }, cts.Token );
task2.ContinueWith(arg =>{ タスク2が終わった後の処理(); }, tskSch);

と、書けます。
一応、上記例は、task1 の終了を待たずに、task2 が動作しています。
task2 が動く前にtask1が終了している必要があるならそのように記述する必要があります。

どうするかは、いろいろあるので、とりあえず書きません。
わかりやすい(将来の自分が見ても、読めるコード)ものを目指していけばよいと思います。

引用返信 編集キー/
■68470 / inTopicNo.10)  Re[4]: C# 並列処理について
□投稿者/ とっちゃん (160回)-(2013/10/22(Tue) 14:14:06)
とっちゃん さんの Web サイト
No68460 (のぶ さん) に返信

>>この、「実装意図を知らない人が見ても」というのは、仕事でしているなら、とても重要です。
>>趣味であっても、半年後の自分はほとんど「実装意図を知らない人」です。
>>「なぜ、こう書いたか」というところを、ドキュメントに残しましょう。
>>そうすると、理解できないコードは理解できるまで使わない、ということも選択肢に上るはず。
>
> 補足ありがとうございます。
> ドキュメントは必ず残します。
> 現状、ドキュメント類の一切ないプロジェクトの保守を行っているのですが、
> 死にかけていますので・・・
> (むしろ、歴代の開発者たちは素晴らしい能力者達だったのでしょう。関数のコメントすらないC++のプロジェクトなので・・・)
>
歴代の開発者が素晴らしかったかどうかはわからんですが
コメント程度でも残すかどうかはそれまでの開発体制やその人の性格、あるいはその時の余裕の度合いなどもあります。

うちの中でも、普段はコメントを書いていても、忙しいときには書いていないとか結構あります。
#コメントと実際のコードが異なっているなんていうのも...


> # 現在社内に主立って開発を行える人がいないので、ネットに頼らざるを得ないのですが、
> # それが本当に正しいのか判断できないのです。(正しいはニュアンスでとらえて下さい)

正しいが外部に求めることを指しているのなら、間違っているということはないと思います。

質問できる環境が身の回りにないのならそれが行える場所を外に求めるか、自力解決を図るかのいずれかです。

前者ならここのような掲示板を利用することになります。ですが、こちらは会社の姿勢として回答や閲覧は構わんが質問はNGというところがあるかもしれません(わかりませんが)。

後者なら、MSDNなどのリファレンスを読む、サンプルをステップ実行したりする、実際にコードとして書き起こして試してみる。
あるいはWeb上をいろいろと検索(中には掲示板なども出てくるでしょう)する。。。

ということを繰り返していくことになります。
日本語の情報がない場合もあるので、英語圏も含めて検索するというのもポイントですが。



それと、もう一つ考慮しておきたいのは、会社の制限事項として問題がないかという部分ですね。
そもそも掲示板でのやり取りはもちろん、閲覧すらNGという企業もあります。

こちらは外部の人間には判断ができませんのでご自身で会社側に聞いてみるなどしてください。
知らずに掲示板でやり取りしてて後で問題にされても、外部に責を問うことはできませんので。

それと、プログラムソースの提示は守秘義務に抵触する可能性があるという点もお忘れなく。
こちらは、その企業がどういうスタンスかにかかわりなく、存在します。
自身に限らず作成したプログラムソースにはいかなるものであれ必ず著作権が付きます。
その扱いはその企業の体制などで大きく変わりますが
仕事上のプログラムソースの多くは会社に帰属することが多いと思います(個人に帰属だと扱いが面倒になるため)。
このあたりの詳細は、開発会社であれば入社以前の段階で説明されているはず(アルバイトでも説明があるレベル)です。

だれが書いても変わらないようなサンプル程度であれば、問題とはしない場合もありますがとらえ方や扱いの問題なので何とも言えません。



> # 皆様はどうやって学習してきのでしょうか?
書籍や雑誌、あるいはWebの記事などで独学がほとんどじゃないですかね。
学校で教えてくれることは限られてるし、昔はともかく、今時は会社で0から叩き込んでくれるようなところはないと思いますし。。。

ただ、ここで一つ覚えておいてほしいのは、漠然と情報に触れていてもそれは身に付きません。
入門書とかにあるプログラムは今ならネットでソースコードをダウンロード出来たりして、実際に手入力することはありませんし
意図したとおりに動くコードしか掲載されていないので即座に実行できて動きが確認できます。
そのため、ざっとソースコードを見てだけでわかった気になってしまうんですよね。

全部手入力しろとは言いませんが、ソースコードを奥深くまでステップインしてみるなど、実際にソースコードに触れてよく見ていくようにすれば、だいぶ違います。

最初は何やってるかわからなくても、リファレンス読んだり実際の動きを見てみるなどを繰り返しているといつのまにか使えるようになりますよ。

引用返信 編集キー/
■68474 / inTopicNo.11)  Re[5]: C# 並列処理について
□投稿者/ のぶ (37回)-(2013/10/22(Tue) 16:04:52)
No68467 (とっちゃん さん) に返信
> .NET 4.5 を利用する場合は、VS2012 あるいはつい先日RTMしたばかりの VS2013(こちらは、4.5.1も利用可能)となります。
> 今後を考えると、早い段階で 2013 に移行してしまうほうがいいかもしれませんね。
>
> セットアッププロジェクトを利用していない場合は。。。となりますが。
セットアッププロジェクトは一切使っていないのでこの辺は問題なく移行できます。
# セットアッププロジェクトなくなったのですね。Wixが取り込まれる(?)と以前お見受けしたのですが、どうなったのでしょう?

> この部分は、基本的にファイルの移動(若しくは、別ドライブにコピーしてオリジナルを削除)とINIファイルに書き込みということでしょうか。
> だとすると、ストレージ(ディスク)アクセスが中心となります。
> INIファイルを作成というのは、ファイルごとに一つではなく、そのフォルダに一つのINIファイルを作成しそこにファイル情報を記述ですよね?
仰る通りです。
ユーザー用フォルダ内にupdateフォルダとINIファイルを作成し、INIファイルには対象ファイル名を記述し、
updateフォルダ内に対象ファイルをコピーするという事です。


> 考え方としては間違っていません。が、思いっきり競合してます。
ハードウェア的に競合するとは思っていませんでした。
ちなみに、単一のINIファイルを複数のプロセスで書き込むという事はしません。

> それを支えるハードウェア上の処理で順次処理となってしまい、並列化の恩恵にあずかれません。
もしかして、今回行いたいファイル移動等だと並列化は(完全にではないにしろ)無駄足になるのでしょうか?


> ここの回答は、Parallel.ForEach の中身に答えのヒントがありますね。
>
> それと、スケジューラオブジェクトは使い捨てではありません。
> スケジューラについては
>
> var tskSch = TaskScheduler.FromCurrentSynchronizationContext();
>
> var task1 = Task.Factory.StartNew(() => { 非同期に処理(); }, cts.Token );
> task1.ContinueWith(arg =>{ 非同期処理が終わったらメインスレッドで処理(); }, tskSch);
> var task2 = Task.Factory.StartNew(() => { 別の非同期処理(); }, cts.Token );
> task2.ContinueWith(arg =>{ タスク2が終わった後の処理(); }, tskSch);
>
> と、書けます。
> 一応、上記例は、task1 の終了を待たずに、task2 が動作しています。
> task2 が動く前にtask1が終了している必要があるならそのように記述する必要があります。
>
> どうするかは、いろいろあるので、とりあえず書きません。
> わかりやすい(将来の自分が見ても、読めるコード)ものを目指していけばよいと思います。
この辺りは今は理解できていないっぽいので一度自分で答えらしきものを探って改めてレスさせて頂きます。
(たぶんContinueWithメソッドの引数にあるTaskContinuationOptionsを使用してtask1終了した場合task2を実行するという書き方かと思いますが、うまくいっていません)
引用返信 編集キー/
■68475 / inTopicNo.12)  Re[5]: C# 並列処理について
□投稿者/ のぶ (38回)-(2013/10/22(Tue) 16:39:07)
No68470 (とっちゃん さん) に返信
愚痴の方にもお付き合い頂きありがとうございます。

ネット上での質問・閲覧等全く制限のない会社ですので、そのあたりは問題なく使用できます。
なので、このように質問し、教えて頂くというありがたい事ができます。

ただし、私自身英語が苦手で極力翻訳を駆使してStackOver(でしたっけ?海外の質問フォーラムって・・)等も読むようにはしているのですが
予約語とかまで翻訳されて意味が分からなくなる事が多々ありまして頭から湯気出してしまう時が・・・

守秘義務に抵触はしないように気を付けてはいます。
今回で言えば実際の拡張子はtxtではなく別の物です。(とか言い出すと抵触するかもよ!っていうお話ですよね)
> このあたりの詳細は、開発会社であれば入社以前の段階で説明されているはず(アルバイトでも説明があるレベル)です。
そうなんですね・・・・

> 全部手入力しろとは言いませんが、ソースコードを奥深くまでステップインしてみるなど、実際にソースコードに触れてよく見ていくようにすれば、だいぶ違います。
ご指導ありがとうございます。
これは私も気を付けています。コピペでは絶対身に付かないと思っていますので、(ほぼ)必ずサンプル、参考サイト等を見ながら手打ちしています。
そして、自分的に分からない箇所はコメントを増やして理解しようとしています。

わざわざ愚痴の方にもお付き合い頂いたのにこのような簡単な返信で申し訳ありません。
正直、吐き出したいもの、お聞きしたいものはまだまだありますが、どう考えても主題と関係ないので堪えておきますw

返信頂いた内容は胸に留めて、仕事に精を出したいと思います。
引用返信 編集キー/
■68477 / inTopicNo.13)  Re[6]: C# 並列処理について
□投稿者/ とっちゃん (161回)-(2013/10/22(Tue) 17:09:59)
とっちゃん さんの Web サイト
No68474 (のぶ さん) に返信
>>セットアッププロジェクトを利用していない場合は。。。となりますが。
> セットアッププロジェクトは一切使っていないのでこの辺は問題なく移行できます。
> # セットアッププロジェクトなくなったのですね。Wixが取り込まれる(?)と以前お見受けしたのですが、どうなったのでしょう?
>
開発当初(具体的にはVS2010当時)には、統合の話がありましたが、当時のVSの開発体制と
オープンソースプロダクトを取り込むことのリスク(リリース体制の違いなど)やその他もろもろの事から
WiX側でアドインを提供する形を続けるということに落ち着きました。

>>この部分は、基本的にファイルの移動(若しくは、別ドライブにコピーしてオリジナルを削除)とINIファイルに書き込みということでしょうか。
>>だとすると、ストレージ(ディスク)アクセスが中心となります。
>>INIファイルを作成というのは、ファイルごとに一つではなく、そのフォルダに一つのINIファイルを作成しそこにファイル情報を記述ですよね?
> 仰る通りです。
> ユーザー用フォルダ内にupdateフォルダとINIファイルを作成し、INIファイルには対象ファイル名を記述し、
> updateフォルダ内に対象ファイルをコピーするという事です。
>
>
>>考え方としては間違っていません。が、思いっきり競合してます。
> ハードウェア的に競合するとは思っていませんでした。
> ちなみに、単一のINIファイルを複数のプロセスで書き込むという事はしません。
>
同一プロセス内の複数のタスク(スレッドと読み替えてもよい)から同時に書き込みに行きます。
Parallel.ForEach()とはそういうものです。

>>それを支えるハードウェア上の処理で順次処理となってしまい、並列化の恩恵にあずかれません。
> もしかして、今回行いたいファイル移動等だと並列化は(完全にではないにしろ)無駄足になるのでしょうか?
>
はい。あまり意味を持つ並列化ではありません。

が、メインスレッドとは別のタイミングで処理するという点は大きなメリットとなります。
実行時間の短縮とは別に、UIスレッドを止めずに動くことができるという点において。。。ですが。

>>一応、上記例は、task1 の終了を待たずに、task2 が動作しています。
>>task2 が動く前にtask1が終了している必要があるならそのように記述する必要があります。
>>
>>どうするかは、いろいろあるので、とりあえず書きません。
>>わかりやすい(将来の自分が見ても、読めるコード)ものを目指していけばよいと思います。
> この辺りは今は理解できていないっぽいので一度自分で答えらしきものを探って改めてレスさせて頂きます。
> (たぶんContinueWithメソッドの引数にあるTaskContinuationOptionsを使用してtask1終了した場合task2を実行するという書き方かと思いますが、うまくいっていません)

まずは、タスクを作る方法を再検討してみましょう。

それと、並列処理に関しては、Webを力任せに検索しても、枝葉末節の知識やテクニックしか手に入りません。

遠回りに感じるかもしれませんが、MSDNライブラリにある内容でよいので、TPL(タスク並列ライブラリ:Task Parallels Library)についての正しい知識を身に着けておきましょう。

引用返信 編集キー/
■68480 / inTopicNo.14)  Re[6]: C# 並列処理について
□投稿者/ とっちゃん (162回)-(2013/10/22(Tue) 17:24:05)
とっちゃん さんの Web サイト
No68475 (のぶ さん) に返信
> ■No68470 (とっちゃん さん) に返信
> 愚痴の方にもお付き合い頂きありがとうございます。
>
> ネット上での質問・閲覧等全く制限のない会社ですので、そのあたりは問題なく使用できます。
> なので、このように質問し、教えて頂くというありがたい事ができます。
>
> ただし、私自身英語が苦手で極力翻訳を駆使してStackOver(でしたっけ?海外の質問フォーラムって・・)等も読むようにはしているのですが
> 予約語とかまで翻訳されて意味が分からなくなる事が多々ありまして頭から湯気出してしまう時が・・・
>
確かにこれはありますね。私も英語は苦手(とりあえず落第しない程度の成績だったのでw)です。
いつも、機械翻訳に頼ってますが、代替日本語はおかしいんですよねw

> 守秘義務に抵触はしないように気を付けてはいます。
> 今回で言えば実際の拡張子はtxtではなく別の物です。(とか言い出すと抵触するかもよ!っていうお話ですよね)
>>このあたりの詳細は、開発会社であれば入社以前の段階で説明されているはず(アルバイトでも説明があるレベル)です。
> そうなんですね・・・・
>
細かいことはここに書いてあるから!の一言という場合もあります。その辺をきちんと説明しているかどうかは
その会社にとってプログラムソースという資産がどの程度価値があるものであるかの感覚によります。

うちの場合仕事の特性もあって、うちのソフトはこれができるから!というのがまだいくつかあるので
そのあたりのソースは門外不出ですね。たとえ協力会社であってもその辺のコードは出しません。
そのあたりが必要なものはうちでコーディングするから。。。と丸ごと飲み込むほうが多いですw


>>全部手入力しろとは言いませんが、ソースコードを奥深くまでステップインしてみるなど、実際にソースコードに触れてよく見ていくようにすれば、だいぶ違います。
> ご指導ありがとうございます。
> これは私も気を付けています。コピペでは絶対身に付かないと思っていますので、(ほぼ)必ずサンプル、参考サイト等を見ながら手打ちしています。
> そして、自分的に分からない箇所はコメントを増やして理解しようとしています。
>
いいことだと思います。ちょっと時間かかりますけど。
まぁ手打ちすることが正しいというわけではありませんが、コードを理解せずにコピペしていないのであれば問題ありません。


> わざわざ愚痴の方にもお付き合い頂いたのにこのような簡単な返信で申し訳ありません。
> 正直、吐き出したいもの、お聞きしたいものはまだまだありますが、どう考えても主題と関係ないので堪えておきますw
>
ぜんぜん。結構みんな、ボソッと愚痴を書いていたりします。
#それと分からないように皮肉にしていたりということもあります。

あとは、あまりため込まないようにしておけばよいかと。
どこか吐き出し口を作る(ブログやツイッターやフェイスブック等々全部パブリックですけどw)とか、勉強会なんかにも顔を出してみて
懇親会や二次会とかで吐き出していくとかw

後ろ向きな愚痴は誰も聞いてくれませんが、前向きな愚痴であれば、嫌われることはありません。
先人の人たちも多かれ少なかれ、難しいと思う部分がありながら進んでいるのでw

引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -