2024年3月 この範囲を時系列順で読む この範囲をファイルに出力する
プロセス間通信を大別しますと、SharedMemory(mmap含む)、Pipe、Queueです。左から「速いけど扱いが難しい」→「扱いが簡単だけど遅い」となるようです。
SharedMemoryは初期定義でメモリサイズを指定しなければなりませんが、型の指定は無く、ポインタを使った変数アクセスの要領で使えます。メモリサイズが最初から固定されるので実質的には型が決まった変数となりますが、読み出してもデータが残ることが特性でしょうか。
PipeはマネージされないQueueと思って捉えています。FIFOみたいな挙動で単純な受け渡しをする一時スタックです。
QueueはPipeが高度にマネージされFIFOまたはLIFOとして機能するイメージです。遅いのが難点ですが、速度を求めないなら便利な手段です。
SharedMemoryとPipeはどちらが速いか論争があるようですが、消さなければ残るメモリーと読みだしたら消える一時スタックというそもそもの違いがある上に、転送速度は誤差レベルの違いしか無いように思われますので、用途に合わせて使い分けるだけかなと・・・。
ネットの情報にも教科書にも、これらの違いを一覧してくれる情報がほとんどありません。関数のパラメータや動作特性などのそもそもの説明がなく、どれが速いか遅いかって比較があればましな方です。コピペの様なソースコードに「俺ってスゲーと思わね?」って感じの斜め上の応用を加えたコードが書かれている物ばかり。説明をしてくれる気持ちはありがたいのだけど、中途半端な応用に本筋が埋もれたサンプルコードを誰が喜ぶのかと疑問を感じたりしています。大変勝手な言い方ですが、検索結果が無駄に多くなって分かりやすい情報が埋もれてしまいますので、ガチのプロは見向きもしない、初心者には伝わらない、そんな「俺スゲーでしょ解説」はお控え願いたいものです。斜め上の応用は書く人それぞれのクセであって一般論とは言い難いのですし。
上記はネット検索で迷宮を彷徨ってしまった思いからの愚痴です。わかってんなら書けよとか言われそうですが、人に教えられる程習得出来たら是非書きたいものです。
#C言語
SharedMemoryは初期定義でメモリサイズを指定しなければなりませんが、型の指定は無く、ポインタを使った変数アクセスの要領で使えます。メモリサイズが最初から固定されるので実質的には型が決まった変数となりますが、読み出してもデータが残ることが特性でしょうか。
PipeはマネージされないQueueと思って捉えています。FIFOみたいな挙動で単純な受け渡しをする一時スタックです。
QueueはPipeが高度にマネージされFIFOまたはLIFOとして機能するイメージです。遅いのが難点ですが、速度を求めないなら便利な手段です。
SharedMemoryとPipeはどちらが速いか論争があるようですが、消さなければ残るメモリーと読みだしたら消える一時スタックというそもそもの違いがある上に、転送速度は誤差レベルの違いしか無いように思われますので、用途に合わせて使い分けるだけかなと・・・。
ネットの情報にも教科書にも、これらの違いを一覧してくれる情報がほとんどありません。関数のパラメータや動作特性などのそもそもの説明がなく、どれが速いか遅いかって比較があればましな方です。コピペの様なソースコードに「俺ってスゲーと思わね?」って感じの斜め上の応用を加えたコードが書かれている物ばかり。説明をしてくれる気持ちはありがたいのだけど、中途半端な応用に本筋が埋もれたサンプルコードを誰が喜ぶのかと疑問を感じたりしています。大変勝手な言い方ですが、検索結果が無駄に多くなって分かりやすい情報が埋もれてしまいますので、ガチのプロは見向きもしない、初心者には伝わらない、そんな「俺スゲーでしょ解説」はお控え願いたいものです。斜め上の応用は書く人それぞれのクセであって一般論とは言い難いのですし。
上記はネット検索で迷宮を彷徨ってしまった思いからの愚痴です。わかってんなら書けよとか言われそうですが、人に教えられる程習得出来たら是非書きたいものです。
#C言語
ホール管理の増員で置きダヌキ。
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは4コアありますが手続き型処理はもちろんマルチスレッドでも1コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはOS次第とはいえプロセスを分散しておけば1コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#C言語 #[Art-Net]
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは4コアありますが手続き型処理はもちろんマルチスレッドでも1コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはOS次第とはいえプロセスを分散しておけば1コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#C言語 #[Art-Net]
寝床を仮組みしました。
懸案の丸ナットを使った接合はイイ感じ。3方向からの2×4材がガッチリ接合されています。斜め材無しにここまで固まるなら他にも使えそうです。
諸々組んでしまったので写真が撮れませんが、バラして塗装する際に記念撮影をしましょう。
ただ、少し寸法間違いをしました。敷板を105mmほど短く切ってしまったのですが、やり直すとコストがかかるし材料も勿体ない。機能は満たしていますので余り材で誤魔化すことにします。
自宅の改装課題はまだまだありますが、大物の目途が付いたので一山越えた気分です。
#ガチ工作
懸案の丸ナットを使った接合はイイ感じ。3方向からの2×4材がガッチリ接合されています。斜め材無しにここまで固まるなら他にも使えそうです。
諸々組んでしまったので写真が撮れませんが、バラして塗装する際に記念撮影をしましょう。
ただ、少し寸法間違いをしました。敷板を105mmほど短く切ってしまったのですが、やり直すとコストがかかるし材料も勿体ない。機能は満たしていますので余り材で誤魔化すことにします。
自宅の改装課題はまだまだありますが、大物の目途が付いたので一山越えた気分です。
#ガチ工作
先週末は現場が被りまくりでオロオロしてましたが、今週は比較的ヒマなので少しはネタを進められそうです。
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#C言語 #[Art-Net]
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#C言語 #[Art-Net]
共有メモリの読み書きのタイミングを考えています。
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は1プロセスで動作します。RaspberryPiでも1プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#C言語
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は1プロセスで動作します。RaspberryPiでも1プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#C言語
今週末はホール管理の増員です。これといってやる事のない置きダヌキです。
Art-Netパッチの処理構造を妄想。
C言語でドライバ部、Pythonでユーザーインターフェース部を作る棲み分けですが、今はドライバ部の構成を整理しています。
これまでの試行錯誤から処理フローを図式化。基本の流れは見えたと思います。
ただ、C言語の構造体を用いた配列処理をもっと突っ込んで覚える必要があります。Art-Netのデータは、レベル値だけでなくメタデータとも言えるインデックスが重要で、カード型データ構造と言ってもいいでしょう。これの追加、削除、抽出、修正を延々と繰り返すので構造体配列を自在に扱えることは必須技能です。
C言語での配列は少し不器用で、私の理解が間違っていなければ、配列をデータベースに見立てたとしてレコードの追加や削除は出来ません。出来ると言えば出来るのですが、特定のレコードを除いた配列全体を新たな配列としてコピーするような操作が必要です。追加も似た様な操作になります。
少しややこしいのですが、次のサイトでは面白い事を書いてます。
C言語 構造体を使ってリスト構造を作るプログラム
C言語の配列に頼らずリスト構造を構成してます。言うなれば手作業で配列操作をするのです。
また、変数名を使わずメモリ領域を確保してポインタで管理しています。一見不合理な使い方に見えますが合理的かも。アセンブラっぽいので私には違和感はありません。
オレメモ
C言語:構造体のメンバのアドレス
C言語 ポインタ同士の引き算
配列が格納されるアドレスとピッチがわかればポインタで配列にアクセス出来ます。処理の内容によってはこの方が速いかも。
この他にも、以前はどうも理解しきれなかったC言語のマルチプロセスや共有メモリ(mmap)のことが理解できた。
Linuxプロセスの生成と実行 fork/exec
C言語でmmap()を用いてプロセス間で変数を共有する
以前の試作でイマイチだったところが解決しそうな期待感。
#[Art-Net]
Art-Netパッチの処理構造を妄想。
C言語でドライバ部、Pythonでユーザーインターフェース部を作る棲み分けですが、今はドライバ部の構成を整理しています。
これまでの試行錯誤から処理フローを図式化。基本の流れは見えたと思います。
ただ、C言語の構造体を用いた配列処理をもっと突っ込んで覚える必要があります。Art-Netのデータは、レベル値だけでなくメタデータとも言えるインデックスが重要で、カード型データ構造と言ってもいいでしょう。これの追加、削除、抽出、修正を延々と繰り返すので構造体配列を自在に扱えることは必須技能です。
C言語での配列は少し不器用で、私の理解が間違っていなければ、配列をデータベースに見立てたとしてレコードの追加や削除は出来ません。出来ると言えば出来るのですが、特定のレコードを除いた配列全体を新たな配列としてコピーするような操作が必要です。追加も似た様な操作になります。
少しややこしいのですが、次のサイトでは面白い事を書いてます。
C言語 構造体を使ってリスト構造を作るプログラム
C言語の配列に頼らずリスト構造を構成してます。言うなれば手作業で配列操作をするのです。
また、変数名を使わずメモリ領域を確保してポインタで管理しています。一見不合理な使い方に見えますが合理的かも。アセンブラっぽいので私には違和感はありません。
オレメモ
C言語:構造体のメンバのアドレス
C言語 ポインタ同士の引き算
配列が格納されるアドレスとピッチがわかればポインタで配列にアクセス出来ます。処理の内容によってはこの方が速いかも。
この他にも、以前はどうも理解しきれなかったC言語のマルチプロセスや共有メモリ(mmap)のことが理解できた。
Linuxプロセスの生成と実行 fork/exec
C言語でmmap()を用いてプロセス間で変数を共有する
以前の試作でイマイチだったところが解決しそうな期待感。
#[Art-Net]
ロックタイト425はいい感じです。
手では全く回せませんが、モンキーレンチとプライヤで強めに回すと外せます。母材も痛みません。止まり具合はM6ボルトでスプリングワッシャを完全に潰してもう一息締めたくらい。素手では無理だけど工具なら外せるという正に願ったり叶ったりのコンディションです。
で、ロックタイト425自体はブチルゴムの様な状態になっています。それほどベタベタはしないけど、へばりついて取れない消しゴムのカスみたいな感じです。
ブチルゴムっぽいからと防水用途に使うには無理がありそうですが、ネジロックにはイイ感じです。
#工具と資材
手では全く回せませんが、モンキーレンチとプライヤで強めに回すと外せます。母材も痛みません。止まり具合はM6ボルトでスプリングワッシャを完全に潰してもう一息締めたくらい。素手では無理だけど工具なら外せるという正に願ったり叶ったりのコンディションです。
で、ロックタイト425自体はブチルゴムの様な状態になっています。それほどベタベタはしないけど、へばりついて取れない消しゴムのカスみたいな感じです。
ブチルゴムっぽいからと防水用途に使うには無理がありそうですが、ネジロックにはイイ感じです。
#工具と資材
2024年2月 この範囲を時系列順で読む この範囲をファイルに出力する
SP13 の筐体はPE(ポリエチレン)ぽい感じです。刻印が無いとPE(ポリエチレン)なのかPP(ポリプロピレン)なのかABSなのか判別し難いのですが、どれも難接着素材です。ホームセンターの選択肢で接着するならスーパーXハイバーくらいです。ただ、本気で接着されるので、最悪の場合に取り外したいニーズに合いません。
ロックタイト271と243を試しましたが硬化せず。これらは金属用であり、嫌気性(空気を遮断すると硬化する)だけでなく金属イオンにも反応して硬化するのは本当の様です。
気になる製品をすべて試すのは不可能ですから、ロックタイト425が良いのでしょうか。超強力な接着をするモノは沢山ありますが、ホドホドの接着をしてくれるものは少ない。手では回らないけど工具を使えば回るって具合いを求めたいのです。
明日入荷なのでお試しです。
追記
モノタロウさんからロックタイト425が入荷しました。
早速試したところいい感じ。求めているのは工具を使えば分解出来るけれど手では動かない固定ですが、正にそんな感じがします。完全硬化は常温で24時間とのことですので、後日あらためて分解テストをしてみます。
比較的高価な接着剤ですがコネクタ1個当たりの使用量はほんのわずかですし、代替品も見当たりませんので価格に疑問はありません。
#工具と資材
ロックタイト271と243を試しましたが硬化せず。これらは金属用であり、嫌気性(空気を遮断すると硬化する)だけでなく金属イオンにも反応して硬化するのは本当の様です。
気になる製品をすべて試すのは不可能ですから、ロックタイト425が良いのでしょうか。超強力な接着をするモノは沢山ありますが、ホドホドの接着をしてくれるものは少ない。手では回らないけど工具を使えば回るって具合いを求めたいのです。
明日入荷なのでお試しです。
追記
モノタロウさんからロックタイト425が入荷しました。
早速試したところいい感じ。求めているのは工具を使えば分解出来るけれど手では動かない固定ですが、正にそんな感じがします。完全硬化は常温で24時間とのことですので、後日あらためて分解テストをしてみます。
比較的高価な接着剤ですがコネクタ1個当たりの使用量はほんのわずかですし、代替品も見当たりませんので価格に疑問はありません。
#工具と資材
PegasysG10 の修理は残すところ信号コネクタを付けるだけです。重作業はアタマを完全に入れ替えないと出来ないのですが、信号コネクタの取り付けなら空き時間に進めることも出来ます。部品や工具を仕舞って次の作業にかかります。
追記
NG灯体は復活したのですが、これからは現役で動いている灯体のケーブルを付け直さないといけません。電源線を2PNCTのTRUE1、信号線を4E6SのSP13にするのです。
これが約27台。NG品ではないものの、同様に全バラ再組み上げなのでそれなりに時間がかかりそうです。
ここまでやれば10年、私が現役のウチは動いてくれるかな・・・。
SP13は端子部、筐体、ケーブルクランプの3要素で構成されますが、それぞれの接続が捻じ込み式。使ってると緩んできますので固定を考えないといけません。
願わくば、普段使いでは外れない、工具を使って頑張れば外れるというとても都合の良い性能が望ましい。完全接着ではない固定です。
普通にイメージすると嫌気性のネジロック剤の塗布ですが、ロックタイトや3Mのネジロック剤には金属専用が多い。嫌気性とは空気に触れなくなると硬化する特性を意味しますが、金属イオンも併用して硬化する物が多く樹脂には不向きです。これは選ばないといけません。
ネット検索によると、条件に合いお勧めされるのはロックタイト425。樹脂の弱接着に推奨されており、瞬間接着剤に分類されていますが数秒ではなく数分で硬化するタイプです。樹脂ネジのロック剤とも謳われています。
ちょっとお高いですが試してみましょう。近所のホームセンターには置かれていませんのでモノタロウさんに発注。
#器具の修理
追記
NG灯体は復活したのですが、これからは現役で動いている灯体のケーブルを付け直さないといけません。電源線を2PNCTのTRUE1、信号線を4E6SのSP13にするのです。
これが約27台。NG品ではないものの、同様に全バラ再組み上げなのでそれなりに時間がかかりそうです。
ここまでやれば10年、私が現役のウチは動いてくれるかな・・・。
SP13は端子部、筐体、ケーブルクランプの3要素で構成されますが、それぞれの接続が捻じ込み式。使ってると緩んできますので固定を考えないといけません。
願わくば、普段使いでは外れない、工具を使って頑張れば外れるというとても都合の良い性能が望ましい。完全接着ではない固定です。
普通にイメージすると嫌気性のネジロック剤の塗布ですが、ロックタイトや3Mのネジロック剤には金属専用が多い。嫌気性とは空気に触れなくなると硬化する特性を意味しますが、金属イオンも併用して硬化する物が多く樹脂には不向きです。これは選ばないといけません。
ネット検索によると、条件に合いお勧めされるのはロックタイト425。樹脂の弱接着に推奨されており、瞬間接着剤に分類されていますが数秒ではなく数分で硬化するタイプです。樹脂ネジのロック剤とも謳われています。
ちょっとお高いですが試してみましょう。近所のホームセンターには置かれていませんのでモノタロウさんに発注。
#器具の修理
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131