➖ 🚶🏼 ⛸️ TPL + DLR =マルチスレッドスクリプト 🕙 👩🏽‍🤝‍👨🏻 🌼

「TPL」（タスク並列ライブラリ）と「DLR」（動的言語ランタイム）を学びたいとずっと思っていました。このために、具体的で、できれば非常に関連性の高いタスクが必要でした。私の翻訳の1つでは、いわゆる「ゲームサイクル」について説明しました。そこで議論されたトピック自体は私にとって非常に興味深いものであり、その上、TPL + DLRバンドルがそのタスクに最も適していると考えています。そこで、軽量の非同期スクリプトエンジンを実装するというアイデアを思い付きました。これは、ゲームを含むさまざまなアプリケーションに簡単にねじ込むことができます。エンジンコアをC＃で実装することにしました。私の場合、動的言語の選択は成り立ちませんでした。これらの目的のために、私は長い間Rubyを選択しています。しばらくの間、私は時々アイデアを育てました。

問題の声明

そのため、複数のスクリプトを非同期に、または特定のスレッドで実行する機会が欲しいです。これを行うには、次のタスクを担当する特定のサービスが必要です。

スクリプトを使用して作業タスクへのリンクを保存する
特定のスクリプトタスクを停止する要求
タスクステータスの追跡
コンソールへのログ出力（StdoutおよびStderr）
ブロードキャストイベントによるコンソールへのテキスト出力の通知

一般的に、このようなもの

そこには何が描かれていますか？ルートノード-" IRE.Instance "-は、スクリプトの動作を調整するサービスそのものの役割を果たすシングルトンです。これを行うために、辞書はシングルトンインスタンスに格納され、各タスクのエントリはRunScriptWithSchedulerおよびRunScriptAsync関数を介して追加されます。名前が示すように、これらの機能はスケジューラによって異なり、その制御下でタスクが起動されます。「RunScriptWithScheduler」を使用すると、たとえばGUIスレッドでタスクを実行できます。 " WriteMessage "および " WriteError " メソッドはどこからでも（スクリプトを含む）利用でき、メッセージログへの出力を目的としています。スクリプトの側では、テキストをサービスログにリダイレクトするために、コンソールへの標準出力メソッドをオーバーライドできます。

サービスタスクディクショナリのエントリは何になりますか？キーは、実行中のスクリプトを識別する一意のGUIDです。このGUIDは、スクリプトの実行を要求したパーティに簡単に転送でき、スクリプト自体のコンテキストに埋め込むことができます。レコード値には、少なくともCancelationToukenSourceおよびTaskへの参照を格納する必要があります。 Taskスクリプトの作成に使用されるCancelationToukenSourceを使用すると、いつでも終了する必要があることをタスクに通知できます。タスク自体へのリンクにより、Continuationを継続できます（ここではTPLについて詳しく説明しません）。

IREサービス

おそらく、エンジンのコア、つまりシングルトンの形式で作成されたサービスの説明から始めましょう。シングルトン実装は、 MSDNから取得されます。また、JAVAのさまざまなシングルトン実装のかなり詳細な分析へのリンクもあります。まだ読んでいない人は読むことを強くお勧めします。

そのため、サービスをマルチスレッドの「ダブルチェックロック」シングルトンとして実装しました。基本実装コードは次のようになります。

シングルトンコメントコード

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading; using IronRuby; using Microsoft.Scripting; using Microsoft.Scripting.Hosting; using System.IO; using System.Threading.Tasks; using System.Diagnostics; using Microsoft.Scripting.Runtime; namespace IREngine { public sealed class IRE { #region Singleton private static volatile IRE _instance; private static readonly object SyncRoot = new Object(); private IRE() { //     //        IRE.Instance //  ,       -  ( , )   // var instance = IRE.Instance; } public static IRE Instance { get { if (_instance == null) { lock (SyncRoot) { if (_instance == null) _instance = new IRE(); } } return _instance; } } #endregion #region Consts //     #endregion #region Fields //     #endregion #region Properties //      #endregion #region Private Methods //       #endregion #region Public Methods //        #endregion } }

構造はコメントから明らかだと思います。コードで説明する特別なものはありません。基本的にシングルトンのコメントを2、3だけ付けます。シングルトンの代わりに、静的ヘルパーを使用できます。しかし、シングルトンライフサイクルは制御が容易です。たとえば、静的コンストラクターの呼び出しの瞬間は非決定的であり、非静的コンストラクターの呼び出しはインスタンスへの最初のアクセスでのみ発生します。これにより、シングルトンを開始する前に将来何かを初期化する必要がある場合、比較的安全に感じることができます。もう1つの興味深い点は、「null」の二重チェックです。 2つのスレッドは同時に最初の条件内に存在できますが、「ロック」はそのうちの1つだけで実行されます。 2番目のスレッドは、最初のスレッドがクリティカルセクションを終了するまで待機します。クリティカルセクションを解放した後、2番目のスレッドはインスタンスの「null」を再度チェックする必要があります。したがって、並列実行スレッドでシングルトンの2つのインスタンスを作成する状況は許可されません。

TPLの使用について簡単に

次に、TPLの基本について簡単に説明します。 CodeProjectで詳細を読むことができます。

最初に作成する非同期タスクは、コンソール出力バッファーの監視です。最初に書いたように、サービスの機能の1つは、コンソールへのメッセージとエラーのロギングです。それで、何が必要ですか？

出力バッファの変更をチェックするアクション
出力バッファをチェックするときのアクションエラー処理
エラーバッファの変更を確認するアクション
エラーバッファをチェックするときのアクションエラー処理
アクションを実行するためのタスクインスタンスを作成するパブリックメソッド

シングルトンのプライベートコンストラクターにアクションの初期化を配置しましょう

初期化アクション

 private IRE() { //     Ruby _outStringBuilder = new StringBuilder(); _errStringBuilder = new StringBuilder(); _outWatchAction = () => { int i = 0; while (IsConsoleOutputWatchingEnabled) { string msg = string.Format("***\t_outWatchTask >> tick ({0})\t***", i++); Debug.WriteLine(msg); WriteMessage(msg); Task.Factory.CancellationToken.ThrowIfCancellationRequested(); int currentLength = OutputBuilder.Length; if (OutputUpdated != null && currentLength != _lastOutSize) { OutputUpdated.Invoke(_outWatchTask, new StringEventArgs(OutputBuilder. ToString(_lastOutSize, currentLength - _lastOutSize))); _lastOutSize = currentLength; } Thread.Sleep(TIME_BETWEEN_CONSOLE_OUTPUT_UPDATES); } }; _outWatchExcHandler = (t) => { if (t.Exception == null) return; Instance.WriteError( string.Format( "!!!\tException raised in Output Watch Task\t!!!\n{0}", t.Exception.InnerException.Message)); }; _errWatchAction = () => { int i = 0; while (IsConsoleErrorWatchingEnabled) { string msg = string.Format("***\t_errWatchTask >> tick ({0})\t***", i++); Debug.WriteLine(msg); WriteError(msg); Task.Factory.CancellationToken.ThrowIfCancellationRequested(); int currentLength = ErrorBuilder.Length; if (ErrorUpdated != null && currentLength != _lastErrSize) { ErrorUpdated.Invoke(_errWatchTask, new StringEventArgs(ErrorBuilder. ToString(_lastErrSize, currentLength - _lastErrSize))); _lastErrSize = currentLength; } Thread.Sleep(TIME_BETWEEN_CONSOLE_OUTPUT_UPDATES); } }; _errWatchExcHandler = (t) => { if (t.Exception == null) return; Instance.WriteError( string.Format( "!!!\tException raised in Error Watch Task\t!!!{0}", t.Exception.InnerException.Message)); }; }

以下は、必要なプロパティ、定数、およびプライベートフィールドの宣言です。

フィールド、プロパティ、定数の初期化

 #region Consts public readonly int TIME_BETWEEN_CONSOLE_OUTPUT_UPDATES = 1000; #endregion #region Fields private bool _outWatchEnabled; private bool _errWatchEnabled; private Task _outWatchTask; private readonly CancellationTokenSource _outWatchTaskToken = new CancellationTokenSource(); private int _lastOutSize = 0; private Task _errWatchTask; private readonly CancellationTokenSource _errWatchTaskToken = new CancellationTokenSource(); private int _lastErrSize = 0; private readonly StringBuilder _outStringBuilder; private readonly StringBuilder _errStringBuilder; private readonly Action _outWatchAction; private readonly Action<Task> _outWatchExcHandler; private readonly Action _errWatchAction; private readonly Action<Task> _errWatchExcHandler; private readonly CancellationTokenSource _scriptsToken = new CancellationTokenSource(); #endregion #region Properties public StringBuilder OutputBuilder { get { lock (SyncRoot) { return _outStringBuilder; } } } public StringBuilder ErrorBuilder { get { lock (SyncRoot) { return _errStringBuilder; } } } public bool IsConsoleOutputWatchingEnabled { get { lock (SyncRoot) { return _outWatchEnabled; } } set { lock (SyncRoot) { _outWatchEnabled = value; } } } public bool IsConsoleErrorWatchingEnabled { get { lock (SyncRoot) { return _errWatchEnabled; } } set { lock (SyncRoot) { _errWatchEnabled = value; } } } public event EventHandler<StringEventArgs> OutputUpdated; public event EventHandler<StringEventArgs> ErrorUpdated; #endregion

このコードは何をしますか？定期的に、StringBuilderの長さが比較され、長さが変更されると、対応するイベントがプルされます。このイベントのハンドラー（GUI側）は、追加されたメッセージテキストを表示します。 GUI側では、ハンドラ内のコードもタスク内で実行されますが、GUIから受信したタスクスケジューラの明示的な指示があることに注意してください。なぜなら GUIスレッドで実行されない非同期タスクではイベントがぴくぴく動くため、ハンドラーのコードはインターフェース要素に直接アクセスできません。メインアプリケーションウィンドウのスケジューラを明示的に指定して、アクションを作成し、インターフェイススレッドで実行する必要があります。以下は、GUI側のイベントハンドラーのコードです。

イベントハンドラーコード

 IRE.Instance.OutputUpdated += (s, args) => { string msg = string.Format("***\tIRE >> Out Updated callback\t***\nResult: {0}\n***\tEND\t***\n",args.Data); Debug.WriteLine(msg); var uiUpdateTask = Task.Factory.StartNew(() => { OutputLogList.Items.Add(msg); }, Task.Factory.CancellationToken, TaskCreationOptions.None, _uiScheduler); uiUpdateTask.Wait(); }; IRE.Instance.ErrorUpdated += (s, args) => { string msg = string.Format("!!!\tIRE >> Err Updated callback\t!!!\nResult: {0}\n!!!\tEND\t!!!\n", args.Data); Debug.WriteLine(msg); var uiUpdateTask = Task.Factory.StartNew(() => { ErrorLogList.Items.Add(msg); }, Task.Factory.CancellationToken, TaskCreationOptions.None, _uiScheduler); uiUpdateTask.Wait(); }; IRE.Instance.StartWatching();

このコードは、コンソール出力バッファーの更新イベントにサブスクリプションを追加します。その中で注目すべき主なものは「 _uiScheduler 」です。これは、メインウィンドウのデザイナーで作成された（ウィンドウ）スケジューラーへのリンクです。このリンクは次のように作成されます。

 public MainWindow() { InitializeComponent(); _uiScheduler = TaskScheduler.FromCurrentSynchronizationContext(); }

このスケジューラで作成されたすべてのタスクは、インストールされているスレッドに関係なく、GUIスレッドで起動されます。グラフィカルインターフェイス要素への短絡は、クロススレッドアクセス例外を引き起こしません。

「 uiUpdateTask.Wait（）; 」という行について。 " try-catch "でこの行をフレーム化することが望ましいです。タスク内で発生するすべての例外は、タスクを作成したスレッドにすぐには転送されません。呼び出しスレッドで例外にアクセスする1つの方法は、Wait（）関数を呼び出すことです。タスクに「継続」を追加して、その中に例外を投稿することもできます。方法は関係ありませんが、例外を処理する必要があります。それ以外の場合、「GarbageCollector」がタスクに到達すると、例外が呼び出しスレッドに送信されます。どの時点でこれが起こるかは不明です。したがって、アプリケーションにとってこれは致命的です。

この場合、簡単にするために、「 try-catch 」は追加しませんでしたが、おそらく後で追加します。ここでのコードは非常に単純ですが、将来はすべてが変更される可能性があります。

コンソール出力を監視するためのタスクを作成するためのコードを提供することは残ります。

 public void StartWatching() { StopWatching(); if (_outWatchTask != null) _outWatchTask.Wait(); if (_errWatchTask != null) _errWatchTask.Wait(); IsConsoleOutputWatchingEnabled = IsConsoleErrorWatchingEnabled = true; _outWatchTask = Task.Factory.StartNew(_outWatchAction, _outWatchTaskToken.Token); _outWatchTask.ContinueWith(_outWatchExcHandler, TaskContinuationOptions.OnlyOnFaulted); _errWatchTask = Task.Factory.StartNew(_errWatchAction, _errWatchTaskToken.Token); _errWatchTask.ContinueWith(_errWatchExcHandler, TaskContinuationOptions.OnlyOnFaulted); }

ここのすべても簡単です。念のため、追跡タスクを停止します（ " StopWatching（）; "）。この関数を呼び出すと、単純に「 IsConsoleOutputWatchingEnabled 」および「 IsConsoleErrorWatchingEnabled 」 フラグが falseに設定され、「 CancelationToken 」のブレークが停止されます。トークンだけに制限することができます。ただし、一般に、トークンを介した停止要求は緊急停止と見なされます。特別な関数 " Task.Factory.CancellationToken.ThrowIfCancellationRequested（）; "もあります。この関数の呼び出しにより、トークンを介したタスクの実行中にキャンセル要求が受信された場合、タスクは例外をスローします。この関数を呼び出して、一般にCancelationTokenのステータスを確認するのは非常にコストのかかる手順です。したがって、できる限りめったに行わないことが望ましい。

次に注意したいのは、「 _outWatchTask.ContinueWith（_outWatchExcHandler、TaskContinuationOptions.OnlyOnFaulted）; 」という形式の構築です。このコードは、いわゆる「継続」（継続）というタスクにハングアップします。さらに、オプション「 TaskContinuationOptions.OnlyOnFaulted 」で継続が作成されます。このような継続は、タスクの「AggregatedException」に少なくとも1つの例外が含まれている場合にのみ呼び出されます。簡単に言えば、タスクが正常に完了した場合、この続編は無視されます。また、いくつかの例外が存在する可能性があることにも注意してください。結局、このタスク内にネストされたサブタスクを作成できます。ネストされたタスクが「 GC 」によって収集されると、未処理の例外はすべて、同じ「AggregatedException」の形式で親にポップアップします。したがって、ネストされた例外のツリー全体を取得できます。この例外ツリーをフラットリストに変換する特別なメソッド「 AggregatedException.Flatten（） 」があります。

スクリプトの基本

それでは、スクリプト自体について話しましょう。まず、「ScriptEngine」を作成し、アプリケーションに必要な.Netアセンブリをロードする必要があります。これは単純に行われます：

 _defaultEngine = Ruby.CreateEngine((setup) => { setup.ExceptionDetail = true; }); _defaultEngine.Runtime.LoadAssembly(typeof(IRE).Assembly);

このコードをシングルトンプライベートコンストラクターの上部に追加しました。コードの最初の部分は、実際にScriptEngineのインスタンスを作成します。パラメーターとして渡されるラムダを使用すると、エンジンを構成できます。これはオプションです。しかし、このアプローチでは、ScriptEngineがRubyコードをコンパイルしないようにして、スクリプトが毎回解釈されるようにすることができます。これは、たとえば、WindowsPhone 7プラットフォームで便利です。メモリを節約します。例外に関する情報の詳細な出力を含めました。

2番目の部分は、サービスを含むアセンブリをRubyエンジンのランタイムに単純にロードします。これがないと、スクリプトからアプリケーションと通信できなくなります。同様に、他の必要なアセンブリをロードできます。一般に、このアセンブリの読み込みを別の方法で行うことをお勧めします。これにより、新しいアセンブリを簡単に追加でき、同時に同じ種類のコード行のシートが目障りになりません。

非同期タスクスクリプトといくつかのサービスメソッドを追加する関数のコードを提供することは残っています。

非同期コードタスクスクリプトの追加

 public Guid RunScriptAsync(string code) { var scriptScope = _defaultEngine.CreateScope(); CompiledCode compiledCode = null; try { ScriptSource scriptSource = _defaultEngine.CreateScriptSourceFromString(code, SourceCodeKind.AutoDetect); var errListner = new ErrorSinkProxyListener(ErrorSink.Default); compiledCode = scriptSource.Compile(errListner); } catch (Exception ex) { WriteError(ex.Message); return Guid.Empty; } var action = new Action(() => compiledCode.Execute(scriptScope)); var tokenSource = new CancellationTokenSource(); var task = new Task(action, tokenSource.Token, TaskCreationOptions.LongRunning); var guid = Guid.NewGuid(); AddTask(guid, new TaskRecord { TokenSource = tokenSource, Task = task }); task.Start(); task.ContinueWith((t) => { // Actually we don't needed this due to "TaskContinuationOptions.OnlyOnFaulted" is set if (t.Exception == null) return; t.Exception.Flatten().Handle((ex) => { Instance.WriteError(t.Exception.InnerException.Message); return true; }); }, TaskContinuationOptions.OnlyOnFaulted); task.ContinueWith((t) => { Instance.RemoveTask(guid); }); return guid; } public void AddTask(Guid key, TaskRecord record) { _tasks.Add(key, record); } public void RemoveTask(Guid key) { _tasks.Remove(key); } public Task GetTask(Guid key) { return _tasks.ContainsKey(key) ? _tasks[key].Task : null; } public void RequestCancelation(Guid key) { var tokenSource = _tasks.ContainsKey(key) ? _tasks[key].TokenSource : null; if (tokenSource == null) return; tokenSource.Cancel(); }

ここには何がありますか？まず、ScriptScopeを作成します。デフォルトのRubyエンジンを使用しますが、各ScriptScopeには独自のスクリプトがあります。すべての変数とスクリプト実行結果のスコープは、これらのスコープに制限されます。

さらに「try-catch」の内部でScriptSourceとCompiledCodeが作成されます。「トライ-キャッチ」が必要ですコンパイル済みコードの作成時に例外が発生する場合があります。この場合、空のGuidを返し、呼び出し側はこの状況を適切に処理する必要があります。スクリプトが正常にコンパイルされたら、スクリプト実行タスクの作成を開始できます。

したがって、スクリプトを実行するアクションを作成し、CancelationTokenSource、オプション「TaskCreationOptions.LongRunning」を持つ新しいタスクを作成します（結局、スクリプトは長時間実行される可能性があります）。次に、タスクの新しいGUIDを作成し、最後に、すべてをスクリプト化されたタスクの辞書の新しいエントリにパックします。最初に計画したとおり。

作成後、タスクを実行し、例外処理を使用してタスクに継続を添付します。タスクの継続では、エラーメッセージをログに書き込んだ後、AggregatedExceptionを「フラット化」し、すべての例外を処理します（ trueを返します ）。

上記の継続に加えて、タスクの完了時に呼び出される別の継続を添付します。この続きでは、使用済みのTaskを辞書から削除します。もはや有用ではありません。

サービス機能を使用すると、すべてがシンプルに思えます。

使用例

このスクリプトフレームワークの動作を示すために、ウィンドウアプリケーションプロジェクトを作成しました。ウィンドウのレイアウトは簡単です。

 <Window x:Class="IREngineTestBed.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="MainWindow" Height="350" Width="525"> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition /> <ColumnDefinition /> </Grid.ColumnDefinitions> <Grid.RowDefinitions> <RowDefinition /> <RowDefinition Height="Auto"/> </Grid.RowDefinitions> <Button x:Name="StartButton" Content="Start" Grid.Row="1" Margin="5" Height="25" Click="StartButton_Click"/> <Button x:Name="StopButton" Content="Stop" Grid.Row="1" Grid.Column="1" Margin="5" Height="25" Click="StopButton_Click"/> <ListBox x:Name="OutputLogList" Grid.Column="0" Margin="5"/> <ListBox x:Name="ErrorLogList" Grid.Column="1" Margin="5"/> </Grid> </Window>

おわりに

ウィンドウには、2つのListBox'aと2つのボタンが含まれています。文字列を追加するパフォーマンスが低いため、TextBlockを使用してログを表示しませんでした（TextBlock.Text + =“ some string”-ご存知のように、大きな悪があります）。しかし、実際にはリストボックスは悪い考えです。テキストをコピーしないでください。一般に、ListBox'yはデモ用です（急いで）。将来的には、RichTextBoxを置き換えることになるでしょう。彼らは文字列の仮想化を持っているようで、テキストはStringBuilderに追加されているようです。

そのため、「StartButton」ボタンを使用して、コンソール出力バッファとスクリプト実行タスクを監視するためのタスクの（再）開始が実行されます。「StopButton」ボタン-すべてが停止します。

テストスクリプトのコードは次のとおりです。

 #!ruby19 # encoding: utf-8 include IREngine class IRE def log(message) IRE.Instance.write_message message end def err(message) IRE.Instance.write_error message end end def log(message, is_err = false) IRE.Instance.log message unless is_err IRE.Instance.err message if is_err end 5.times{|i| log "Hello, Output! (from Ruby Async Task)" log "Hello, Error! (from Ruby Async Task)", true } raise "\n!!!\tBOOO! Catch super scaring exception from RUBY...\t!!!\n"

このコードでは、メッセージをログに出力するヘルパーメソッドがサービスクラスに追加されます。さらに、シングルトンインスタンスに追加のメソッドが追加されます。しかし、メソッドの名前に接頭辞「self」または「IRE」を付けた場合、それらは静的メソッドとして作成されます。おそらく後で行います（このケースを個別にテストする必要があります）。

スクリプトの本文には、ログへの行の5倍の出力と例外転送が表示されます。この例外は、サービス側で正しく処理されます。これは、スクリプトの実行後のインターフェイスの外観です。

おわりに

この記事では、複数のスクリプトを同時に非同期で実行できるエンジンの基本的な実装を紹介しました。執筆時点では、すべての計画が実装されているわけではありません。たとえば、スクリプトの構文エラーの状況の処理の正確性を確認する必要があります。また、特定のスケジューラーを示すスクリプト起動メソッドはまだ実装されていません。

githubのリポジトリでコードの開発をフォローできます。誰かがプロジェクトの開発に参加してくれたら嬉しいです。

ご清聴ありがとうございました！

TPL + DLR =マルチスレッドスクリプト

問題の声明

IREサービス

TPLの使用について簡単に

スクリプトの基本

使用例

おわりに

おわりに

More articles: