xojoはアメリカのxojo社が開発/提供しているクロスプラットフォームな開発環境でオブジェクト指向型のBASIC似た構文を
持った独自な言語です。
独立したアプリケーションを生成出来ますので、マイクロソフトのVisualBASICの代替やFileMaker等の
データベースを扱うアプリケーションの置き換えなどに重宝します。
【特徴】
・アプリケーションを生成しなければライセンスは不要である。
・Windows、MacOS、Linux、iOS、アンドロイド、等のターゲットに多くのソースコードが共有出来る。
・学生などには申請により無償でライセンスが提供されるケースがある。
・平易な構文やキーワードで簡単に学べる。
・多くの外部SQLデータベースに接続できる。
・SQLiteは組み込みで使える。
等々
使って見るのは只なので、誰でも簡単に始められます。
https://xojo.com
(英語のサイトですが簡単な英文ですので、翻訳機能片手に進んでいけます)
でユーザ登録から始めてください。
xojoのオープンソースなプロジェクトがいくつかあるそうなので、xojo.comのドキュメントサイトも見てください。
https://documentation.xojo.com/resources/third_party/open_source_projects.html
xojoの日本語フォーラムもありますが、最近はほとんど使われていないようです。
XojoのThreadクラスを知っていますか?
Threadクラスと聞いても、何の事かも判らないし、得体の知れない物と思われているかも判りませんが、
簡単な例を上げてみると:
通常のプログラムは
1)ユーザから何かの入力を受けて、加工を施してから画面に表示します。
また
2)ファイルやネットワークからデータを読み込んで、加工して画面に表示したり、
別のファイルに書き出したりします。
この様な場合に、加工すべきデータが数十〜数百の程度だと現状のパソコンでも、
処理内容にも拠りますがほぼ数秒以内に結果が得られます。
しかし
加工すべき元データが数万〜数千万の単位になると、数分もしくは数時間掛かるかも知れません。
その作業時間にユーザからのアクションである各種イベントが処理されなくなると、どうなるでしょうか?
・プログラムが暴走orハングアップしたのか?
・何か間違った捜査をしてしまったのでは無いか?
・指定すべきデータを間違ったのでやり直したい!
等と言う状況になるかも…
そのような場合に役立つのが、Threadクラスや別途説明するWorkerクラスです。
(今回はThreadクラスの説明ですので、Workerクラスは別の機会にします)
加工処理に時間がかかる場合、ユーザに状況を把握してもらうため
・ダイアログウィンドウ等を表示して、全データ件数の内の何件目を処理しているのかを表示する。
・ユーザからの途中での停止、中断等のアクションを受けて、適切な対応をする。
みたいな動作をする事が望ましいと考えられます。
そこで、アプリケーションの本来の流れはダイアログウィンドウを表示し、データ加工の進行状況を
更新しつつ、イベントを適切に処理しておく事で、ユーザはいつでもアプリケーションを安心して
使用できます。
本来の流れとは別に(Threadクラスを用いて)データ加工を順次行う事で、プログラムの流れを分離して
簡潔な構成にして、作成が容易になり、バグの発生も軽減できる事が期待できます。
但し、Threadの処理内ではThread SafeなAPIしか呼び出す事が出来ません。
具体的には画面への表示更新などはThread Safeでは無いので、呼び出す事は出来ません。
ご注意ください。
閑話休題
とっても面倒くさい様な話を降り出したのですが、何かおかしいぞと思ったアナタ!
ヨクゾ気付きました。エライ、エライ、 なでなでしてあげます(^o^)
昨今のパソコンはCPU等が高機能化し、4コアや8コア程度は当たり前、お金を出し惜しみしなければ
32コアとか128コアとかのCPUを選ぶ事も出来ます。
但し、WindowsのクライアントOSは32コアを超えるCPUコアはサポートされず、使用されません。
であるのであれば、そんな時間のかかる場合はコンパイラやOSが適当に割り振ってくれても
良いのでは無いかと思いませんか?
まぁ、そう考えるのが普通ですな!
でも、現状のOSやコンパイラは、
・どの部分が時間のかかる処理か
や
・どの部分が別のコアに割り当てても問題が無いか
を判断する事がいまだ出来ていません。
ですので、プログラムを記述する我々が適切に明確な指示をしない事には
プログラムの分離はできないのです。
21世紀になったら、どら衛門や100万馬力のロボットが出来ていて、プログラミングから開放されると
夢見ていた自分を殴ってやりたいです。😂
〜〜蛇足〜〜
確かにコンパイラの最適化は進歩しました。インテルのコンパイラなどはベンチマークテストのコードを
何事もなかったかの様に処理して、ほとんど空のコードを吐き出して、唖然としました。
昔々、パソコンがまだ一般的じゃなかった頃、会社で導入したコンピュータでとあるシュミレータを
作って居た頃でも、並列化の部分はゴリゴリと手作業で書いていました。
WindowsもmacOSもAPIやライブラリは豊富にそろっていますが、基本的な部分はIBMのOS/370や
DECのVMSとそうは変わっていないように思えます。
ですので、若い方々の努力の参考になれば幸いです。<m(__)m>
xojo Rel.2024r3でThreadに新しい機能が追加されました。
ThreadクラスがPreemptive機能をサポートします。
デフォルトではCooperativeですが、IDEで設定を変更する事でPreemptiveに
する事が出来ます。
Preemptive threadsを使うにはいくつか注意点があります。
Preemptiveスレッドを作成するには、Type プロパティを Preemptive に設定します。
実行時にスレッドのタイプを変更できますが、スレッド内のTypeプロパティのみが変更可能です。
実行中の他のスレッドのTypeプロパティを変更しない様に注意が必要です。(してしまうと、クラッシュします)
また、ロック中(セマフォアやクリチカルセッション中)にTypeを切り替えるとクラッシュしたりロック
(フリーズ)します。
デフォルトでは、スレッドはcooperativeであり、全てがアプリと同じCPUコアで実行されリソースも
共有しています。
これは、実行すべき処理が多いほどスレッドが完了するまでに時間が掛かります。
Preemptiveスレッドはアプリ自体とは別のCPUコアで実行する事が出来ます。
そのため、CPUコアに余裕があれば、cooperativeスレッドよりも速く実行できる事です。
Preemptiveスレッドは、スレッド間やアプリとの間でメモリを共有しません。
つまり、スレッド内のコードはアプリの他のオブジェクト等のメモリにアクセス出来ません。
*個人的な見解ですが*、セマフォアやクリチカルセッションを使う事で
ArrayやDictionaryを扱える筈です。
その際はセマフォアやクリチカルセッションのTypeプロパティをPreemptiveにする必要が有ります。
これを忘れるとIllegalLockingExceptionになるようです。
xojoがサポートする機能のいくつかはPreemptiveスレッドから利用出来ません。
(この項目に関して、特定の情報は見つけられなかったです。)
cooperativeスレッドと同様に、UIに直接アクセス出来ません。
Runtime.IterateObjectsメソッドとXojoScriptは、Preemptiveスレッドで安全に使用できません。