<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title><![CDATA[ No.835 - 電装工芸日記 - 舞台照明機器の製作とか - ]]></title>
	<link>https://www.densokogei.jp/tegalog/tegalog.cgi</link>
	<description><![CDATA[ 今年は開発案件を進めたい ]]></description>
	<language>ja</language>
	<copyright>Copyright 2026</copyright>
	<lastBuildDate>Tue, 21 Apr 2026 06:51:15 +0900</lastBuildDate>
	<generator><![CDATA[ <!-- てがろぐ Version: -->Powered by <a href="https://www.nishishi.com/cgi/tegalog/" target="_top">てがろぐ</a> Ver 3.4.0 ]]></generator>
	<!-- BEGIN ENTRIES -->
	<!-- One Entry Data for RSS Feed -->
<item>
	<title><![CDATA[ 　ホール管理の増員で置きダヌキ。 ]]></title>
	<description><![CDATA[ 　ホール管理の増員で置きダヌキ。<br />　こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。<br />　構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは４コアありますが手続き型処理はもちろんマルチスレッドでも１コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはＯＳ次第とはいえプロセスを分散しておけば１コアだけに負担がかかることは無くなるので良いかなと思うのです。<br />　現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。<br />　注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。<br /><br /><a href="https&#58;//www.densokogei.jp/tegalog/tegalog.cgi?tag=%ef%bc%a3%e8%a8%80%e8%aa%9e" class="taglink" title="Ｃ言語">#Ｃ言語</a> <a href="https&#58;//www.densokogei.jp/tegalog/tegalog.cgi?tag=%41%72%74%2d%4e%65%74" class="taglink" title="Art-Net">#&#91;Art-Net&#93;</a> -- Posted by 電装工芸 〔591文字〕 ]]></description>
	<link>https://www.densokogei.jp/tegalog/tegalog.cgi?postid=835</link>
	<guid>https://www.densokogei.jp/tegalog/tegalog.cgi?postid=835</guid>
	<category>tegalog</category>
	<pubDate>Sat, 16 Mar 2024 22:03:19 +0900</pubDate>
</item>

	<!-- END ENTRIES -->
</channel>
</rss>

