問題タブ [retlang]

チャネル入力を優先的に処理するにはどうすればよいですか? reactWithin(0) { ... case TIMEOUT }Scala の " " コンストラクトに相当するものはありますか?

プロデューサー/コンシューマーのバインドされたキュー、単一のプロデューサーに対する複数のコンシューマーを実装する必要があります。

アイテムをキューに追加してから最大サイズをチェックするプッシュ機能があります。到達した場合は false を返し、それ以外の場合は true を返します。

次のコードでは、_vector は List<T> であり、onSignal は基本的にアイテムを非同期で消費します。

このコードに問題はありますか?

Retlangを使用しているときに、チャンネルから退会するための最良の方法がわかりません。

電話で購読するとISubscriber<T>::Subscribe(...)、が返されますIUnsubscriber。このインターフェースにはメソッドがありません。

レベルを上げると、IChannel<T>メソッドもありません。

私が考えることができる唯一のことはISubscriber<T>、コンクリートにキャストしてChannel<T>そのメソッドを呼び出すか、にメソッドをUnsubscribe()追加することです。Unsubscribe()ISubscriber<T>

私がコードを変更する前に、誰かが彼らが何を考えていたかを知っているかどうか、私はただ興味があります。

私は現在、優れたライブラリである.NETのメッセージベースのマルチスレッドにRetlangを使用しています。明示的なロックはもうありません。すべてのスレッドが独自のビジネスを行っており、アプリケーションの一部を管理し、メッセージを介して他のスレッドと通信しています。

ここで、独自のパブリッシャー/サブスクライバースレッドを持つことができるアプリケーションの機能を実装する必要があります。唯一の問題は、このスレッドが実際に実行する作業が非常に少ないことです。約10分ごとに発行元からメッセージを受信する予定です。メッセージを受信すると、それはいくつかの作業を行いますが、数百ミリ秒以上かかることはありません。

それで、99.9％の時間スレッドをスリープさせることが実際に良い選択であるかどうか疑問に思い始めました。この種の操作にはスレッドプールがありますが、メッセージを受信するスレッドを制御できないため、エラーが発生しやすい醜いロックを使用する必要があります。

私の質問は、スレッドをアイドル状態のままにして、大部分の時間を待つことは、リソースの面で本当に問題なのかということです。優れたメッセージベースのアーキテクチャを使用した後に共有マルチスレッドを使用すると、過去にさかのぼるような気分になります。さらに、ロックを備えたアプリケーションの唯一の部分になります。しかし、私は「ここで何か間違ったことをしているのだろうか」と考え続けています。このスレッドで。

編集：皆さん、ありがとうございました。すべての回答を読んだ後、別のスレッドはそれほど問題ではないと判断しました。私のアプリケーションは、メッセージベースのマルチスレッドのみで一貫性を保ちます。パフォーマンスに本当に問題がある場合は（ただし、そうではないはずです）、さらに調査します。

私がウェブ上で見つけることができる Retlang の例/チュートリアルはすべてかなり古いようです。

http://ayende.com/Blog/archive/2007/11/01/Retlang--Concurrency-Library-for-C.aspx

http://www.colourcoding.net/blog/archive/2010/05/28/tweaking-the-retlang-queue-channel.aspx

もちろん、テストがあります。他に何か？

オブジェクトのいくつかのインスタンスが同時に「パルス」を生成するアプリケーションを構築する必要があります。(基本的に、これはカウンターをインクリメントしていることを意味します。) また、各オブジェクトの合計カウンターを追跡する必要もあります。また、カウンターで読み取りを実行するたびに、カウンターをゼロにリセットする必要があります。

職場の男性と話していたのですが、彼は Retlang とメッセージベースの同時実行性について言及しましたが、これは非常に興味深いものでした。しかし、明らかに私はその概念に非常に慣れていません。小さなプロトタイプを作成したところ、予想どおりの結果が得られました。これは素晴らしいことです。しかし、Retlang と並行プログラミング全般。

まず、私はこれらのクラスを持っています：

ここでの考え方は、複数の Plc をインスタンス化し、それぞれに同じ IChannel を渡し、それらに SendPulse 関数を同時に実行させることで、それぞれが同じチャネルにパブリッシュできるようにするというものです。しかし、私のコメントからわかるように、私がやっていることは実際に合法であるかどうかについては少し懐疑的です. 私は主に、同じ IChannel オブジェクトを使用して異なる IFiber のコンテキストでパブリッシュすることについて心配していますが、エンキューに渡されたデリゲートから決して返されないことについても心配しています。これをどのように処理すべきかについて、誰かが何らかの洞察を提供できることを願っています。

また、「サブスクライバー」クラスは次のとおりです。

ここでは、Plc インスタンスに与えられたのと同じ IChannel を再利用していますが、別の IFiber がそれにサブスクライブしています。理想的には、各 Plc からメッセージを受信し、クラス内の単一のプライベート フィールドを更新できますが、スレッド セーフな方法で行うことができます。

私が理解していること (およびコメントで言及したこと) から、Plcs から各メッセージをシリアルに受信するため、Subscribe 関数に渡したデリゲートの _pulseTotals 配列を更新するだけで安全だと思います。

ただし、合計を読み取ってリセットする必要があるビットを処理する最善の方法がわかりません。コードとコメントからわかるように、_pulseTotals 配列へのすべてのアクセスをロックでラップすることになりました。しかし、これが必要かどうかはわかりません.a）実際にこれを行う必要があるかどうか、およびその理由、またはb）同様のものを実装する正しい方法を知りたいです.

そして最後に、私の主な機能は次のとおりです。

1 つの IChannel をインスタンス化し、それをすべてに渡します。ここで、Receiver は内部的に IFiber をサブスクライブし、Plc は IFiber を使用して、継続的にチャネルにパブリッシュする戻りのないメソッドを「エンキュー」します。

ここでも、コンソール出力は、私が期待していたのとまったく同じように見えます。つまり、10 秒待った後、Plc 1 に対して 20 個の「パルス」が表示されます。また、読み取り後のカウンターのリセットも機能しているようです。つまり、Plc 1 には、10 秒ごとに 20 個の「パルス」があります。しかし、それは私が何か重要なことを見落としていないことを保証するものではありません.

Retlang と並行プログラミングの手法についてもう少し学べることをとても楽しみにしています。そのため、誰かが私のコードを調べて、私の特定の問題に対する提案や、私の要件に基づいた別の設計を提供してくれることを願っています!