2026年4月6日月曜日

visual studio C# Rev.0.4 通らぬ引数

本日もC#でアプリのデバッグをやっている.

アプリ画面のプルダウンリストで設定を選ぶ
 →なぜかアプリ動作に反映されない

という悩みで昨日あたりから悩んでいた.

内部を調べると、表示ルーチンの中に引数が入って行かない.そんなことある?

ところが動かし方を変えると正常化する.
アプリ画面を一旦停める
 →プルダウンリストで設定を選ぶ
  →再度動かす
   →アプリ動作に反映される

あっ、と気づいた.

その表示ルーチンは
 Task.Run(() => DataLoop(select))
なる別スレッドを起動したら勝手にloopで自走するのであった.
通らない引数はselectである.

スレッド起動時に渡した引数はloopを停めるまで不変なのだった.これが原因.

とすると、プルダウンリストを選んだら表示を一旦停めて再起動しなくちゃいけないじゃない.ダル~

あ~ぁ もう今日は投了だぁ投了

ーーーー
これが出ました.コピロットに月額$10支払えと言われました.お金を払わないと4月はもう使えません.やっぱり限度があった.
お金を支払いました.¥1597だったかな.円安.

ーーーー
さてAIにこんな質問を投げた.
「static methodをthreadでRUNさせて永久loopさせる.そのstatic methodに外部変数を随時与えたい.どうしたらいい?」

AIはまずこんな回答を出してきた.
「直接引数で渡そうとすると、スレッド開始時の値で固定されてしまう」
そうそうまさにこの症状なんだよ.

AIはさらに続ける.
「引き渡すのが数値(int)1つであれば、最もシンプルで確実なのは volatile 修飾子 を使った共有変数か、より厳密なスレッド安全性を確保できる Interlocked クラス を使う方法です」
意味わかんねぇ....

どうやらこうゆうことのようだ.
まず、thread RUNされる側のclassでUIに即時反応させたい変数を宣言しとく.
 public static volatile int scale_sel = 0;
volatileをつけるのが重要.

つぎに、上位のUI classでプルダウンリストが変化したときに、
 DataCal.scale_sel = 1;
のようにthread側の内部に直接手を突っ込めばよい.
少し気味が悪いが動くようになった.

かしこ

19 件のコメント:

  1. ポンコツ風紀委員とスカートの丈が不適切なJKとの話
    くらいでいいでしょうか 本日 毒者

    返信削除
  2. すごい、もう自分の手の届かない高みに到達しているような・・。
    スレッドってメモリを共有できないからスレッドなんだろうなくらいの考えでいたので、UIから走りっぱなしのスレッドに値を渡せるとは思っていませんでした~。
    vlolatileはcではコンパイラの最適化に引っかかってメモリクリアやレジスタアクセスなどのときの変数アクセスを消されないように付けていたやつですかね。こういう使い方もできるんですね。
    $10は安いですね。claudeは$20くらいだったかと。今はもっと値上がりしているかも。

    返信削除
    返信
    1. ひら的にも「ここでvolatileがでるんか?」と思っちゃいました
      C言語ではおなじみのvolatile
      いや、組み込みのCにしか出てこないのかな?

      値を渡すというよりも、
      threadにグワッと手を突っ込むのがなんだかなぁ

      奥さんはgeminiに¥3000と言ってたので、
      コピロット¥1500はたしかに安い

      削除
    2. volatile最強ですね。そもそも自分がスレッドを勘違いしていました。同一プロセスの中のスレッド間ではメモリを共有できるんですね。この記事を読んでからGeminiに聞いてわかりました。プロセスとスレッドを混同していました。同一プロセス内であれば論理アドレスと物理アドレスが一致するので、スレッド間でメモリを共有できるとのことでした。volatileは必ずキャッシュによる不具合を取り除いてくれるようです。勉強になりました。

      削除
    3. 投了しなくて粘ってよかったです

      麻雀で勝つ方法: 勝つまで半荘を続ける

      削除
    4. >threadにグワッと手を突っ込む
      まぁ、スレッドは「メモリ空間的」には同一なので「volatile」は、単に
      ・コンパイラの制限を取り除いただけ
      だけだと思いますが。
      ※これが「プロセス」とかになると、「別メモリ空間」になるので、そう簡単には行きません。ポインタを変数に取っとくと、スワップアウトされてて「アクセスエラー」(運が悪いと、ブルースクリーン)に成ることがあります。
      VC++ とかで、イロイロ実験するとわかります。

      削除
  3. 「volatile 」何それおいしいの?
    僭越ながら、c# のそんなキーワード知りませんでした(笑)勿論、使ったこと無いです。
    ※イロイロ調べたら、各種言語(Java とか)にもあって、言語によって微妙に使用は違いますが、要するに、
    ・マルチタスクやスレッドで、同期処理でよく使う機能
    であることは分かりました。
    ※ちなみに私はそういう時は「lock(SycLock)」とか使ってます。
    どーでもいいのですが、前に言ってた「Marshall」も、やってることは似たようなことです。まぁ COM も、マルチスレッドの一種だし。
    >もう自分の手の届かない高みに到達しているような・・
    私も同感です。アレだけのヒントで、ココまで提示できるってスゴイと思った。
    ※このソ-ス見て無いので分かりませんが、この人はあんまり良く分かってないで作ってるような気もしてきました。
    今は「ネタソース」なんてネットにあふれてるんで、どこかから「Copy&Paste」で、ソレっぽいもの出来ちゃうからなー。
    (アレ?、それってどこかで聞いてような・・・AIですか?)

    返信削除
    返信
    1. ソフト屋さんから褒められました
      これを糧に生きてゆくことができます

      このPCアプリはかつては2名のソフト屋さんが作っていました
      足回り担当と、内装担当みたいな2名チーム
      足回り担当者が先に抜けて、
      内装担当者がつい先日抜けたと

      そのせいで、
      足回りオブジェクトが別ファイル感覚で切り分けられていて、
      内装が4500行の巨大ファイルになっている、
      そんな構造になってるなぁと見ていて思ふ

      ほいで足回りに手を突っ込まなくちゃいかんくなってトラブりました~

      これはrefactoringの出番ですか? >コピロット

      削除
    2. >足回りオブジェクトが別ファイル感覚で切り分けられていて
      コレは、「画面回り」と「処理ロジック」と言うコトでしょうか?
      VisualStudio でプログラムを作ると、デフォルトで、
      なんとか.cs(処理ロジック)と
      なんとか.Designer.cs(画面回り)の、
      2つのファイルが勝手に出来ます。
      この2つは「partial」に成っているので、実際は「1つのファイル(クラス)」を分割して居るダケです。
      なので「どっちに記述しても」結果は同じです。
      ※↑ は「ふつーの WinFormの c# プログラム」で、
      昔試しに作った wpf アプリでは、
      App.xaml.cs (処理ロジック)
      MainWindow.xaml.cs (画面回り)
      に成ってますね。(どっちにも、.xaml ファイルが付いてるのが謎。この辺で「嫌気が差して」やめた(笑)
      2人で、一個ずつ担当してたのかな?
      最近の VisualStudio では、ファイル構成が違うかもしれませんが・・・
      ※VS2022 でも、基本ファイル構成は同じでした(笑)
      .NET8 で、サンプル動かしてました・・・

      削除
    3. 内装:画面と描画とUIとtimerとthread ON/OFF
      足回り:USBと信号処理とコンフィグ

      ってかんじですかね
      Appはあまり記述がないです

      描画の付近に信号処理が分散して入ってるのが
      いかにも2人でやってたっぽい

      削除
    4. >描画の付近に信号処理が分散して入ってる
      あ、ソレ「ハマる作り方」ですね・・・
      ※「描画系」と「処理ロジック系」は、
      ・混ぜるな危険
      です・・・
      ※コレは、Windows App の話なので、.NET は、その辺が考慮されてるかもしれませんが、よく知りません。
      まぁでも、Windows で動かしてる時点で、同じなような気がしますが。
      「画面(UI)」と「信号処理」は、ホントは「プロセス分離」するべきですが。(最低でも「スレッド分離」はしないと、処理が追い付かなくなるハズ。)
      この辺は、STM32 とかの KnowHow が、そのまま使えると思います。あっちも「曲がりなりにも」32bit CPU なので、結構高度な処理出来るし。
      ※たまに(と言うか良く)「ボタンのクリックイベント」とか自体に、
      ・ゴリゴリの処理ロジック書いちゃう人
      がいますが、そんなことやると「処理が終わるまで」画面がフリーズします(笑)
      つか、ソコに「サブCPUとの通信」とか入れたら、
      ・永久に帰って来なくなって
      (勿論「終了ボタン」(右上のx)とかも効かなくなって、終わらせることすらできなくなる(笑)私はそんなソフトばっかり見て来ました・・・)
      ※流石に、そこまで酷くは無いと思いますが(笑)

      削除
    5. コピロット、なんとかして!

      困ったときにはドラえもん

      削除
  4. 神奈川県人
    >このPCアプリはかつては2名のソフト屋さんが作っていました
    このアプリを平坂さんが一人でメンテナンスですか?(@o@;
    お疲れ様です。m(_._)m「自分は無理です」
    発注側からすると2人(ソフト)+1人(ハード)が1人になるので経費的には
    60%カットですね。
    雛形があればメンテナンスはそれほどパワーは必要ないですが、短期間でソフトを理解して修正して行けるのはすごいです。
    昔上司でC言語を3日で覚えた人がいました。
    技術者としてはすごい人で尊敬して近づこうとあがいたのですが、自分はその中腹にすら近づくことすらできませんでした。orz

    >これはrefactoringの出番ですか?
    この前に業務契約変更じゃないですか?
    ハード担当からソフトも追加なので、最初の条件と違っている気がします。
    社員になるという事でしたので、給与の大幅ベースアップを獲得できるのではないでしょうか?
    (確定申告していたからもしかして業務委託契約?)

    返信削除
    返信
    1. とにかく雛形を作ってもらいました.

      元:
      電気屋3名(自分含む)
      ソフト屋2名
      メカ屋0名

      現在:
      電気屋1名(自分含む)
      ソフト屋0名
      メカ屋0名

      ↑あれぇ?

      削除
    2. あとコピロットを雇った

      削除
  5. >お金を支払いました
    早速、私の予言通りに成ってますね・・・(笑)
    ※気づいたら、「課金地獄」に成ってたりして。
    トークンなんか「あっという間に」消費されちゃいそう。仕事で使ってるし。

    返信削除
    返信
    1. そうなんですよ
      預言成就
      アカシックレコード
      運命は変えれない

      削除