電装工芸日記
- 舞台照明機器の製作とか -
2022年12月28日の投稿(時系列順)［2件］
マルチプロセスについて調べていました。
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
書き方を考えています。
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語