Данная библиотека Вам пригодится, когда Вам необходимы несколько таймеров с независимой обработкой и неконфликтующие между собой. Для работы с данной библиотекой важно запомнить следующие правила: В теле вашей программы не должно быть функции OnTimer , т.к. эта функция уже присутствует в файле Timer.mhq Не надо создавать никаких экземпляров...
その客観的な理由を詳しく教えてください。
理不尽なブレーキ
ここで書かれていることが理解できない人は、ごめんなさい、私の問題ではなく、話題のタバコを吸わない人の問題なんです。
いいえ、それはあなたの問題です。論点も意味合いも理解せずに持ち出したのはお前だろう。
10年以上前から、ここで何度も議論されてきたことです。
理不尽な速度低下
では、イベントループで動作するタスクマネージャーが、複数のタスク（ハンドラの数と同じ）をばらまくと、スローダウンが発生するのでしょうか？
何しろ、ハンドラーはそんなにたくさんいるわけではなく、数人しかいないのですから。タスクの中に散らばって、それぞれのイベント ループに解放されればいいのです。
同時に、ハンドラの実行フラグを制御する。ハンドラが動作し、フラグがリセットされ、といった具合に。
なぜか、スローダウンは信じない、すべてのイベントを処理するのではなく、同数のハンドラのみを処理する。
そして、ハンドラ自体も独自のイベントを持つ。
では、イベントループで動作するタスクマネージャーが、複数のタスク（ハンドラの数と同じ）をばらまくと、スローダウンが発生するのでしょうか？
ハンドラーはそんなに多くなく、数人程度です。タスクの中に散らばって、それぞれのイベント ループに解放されればいいのです。
同時に、ハンドラの実行フラグを制御する。ハンドラを実行し、フラグをリセットする、など。
それはブレーキに戻ることはありません、それはすべてのイベントが処理されるのではなく、ハンドラの数が等しいだけです。
ハンドラにはそれぞれイベントがあります。
書き手がいるところでは、読み手は待たされることになる。作家が書くまで。
複数のリーダーがある場合は、それぞれのリーダーで変数をネゴシエートする必要があります。1人の転生者が変数の内容を変更している間、他の転生者は待機しています。たとえ現時点で他の化身が存在しなくても、リソースのロックはシステムコアに行われるため、高価な操作となる。すべての化身が取引環境を追い求めてからが本番です。同時に取引を開始するとは、神業です。
全体として、若者は言われたことに耳を傾けないのです。繰り返しています。事例を交えて解説付き。10年以上連続で
いいえ、これはあなたの問題です。論点も結果も理解せずに持ち出したのはあなたです。
10年以上前から、ここで何度も議論されてきたことです。
反対派からは、建設的な議論というより、不十分な攻撃ばかりが目につく。
もし、あなたがタイムリーに介入して問題を明確にしていれば、不必要な質問はなかったはずです。
そして、開発者が黙っていると、何を考えているのかわからなくなる。この10年でテクノロジーの世界は大きく変わりました。
なるほど、私の話を聞いてくれたということは理解できたので、この問題についてもう一度考えてみてほしい。もしかしたら解決できるかもしれない、それはとてもクールなことだ。
相手からの不十分な攻撃ばかりで、建設的な議論ができていない。
もし、あなたがタイムリーに説明を介入していれば、不必要な質問はなかったはずです。
また、開発者が沈黙していると、何を考えているのかわからなくなります。この10年でテクノロジーの世界は大きく変わりました。
なるほど、私の話を聞いてくれたということは理解できたので、この問題についてもう一度考えてみてほしい。うまくいくかもしれませんね、本当にかっこいいです。
不十分な攻撃は、"シッ、またか"。
答えはすべて正常だった。攻撃はあくまで自分から。気を悪くされたのなら、ごめんなさい。
そして、男たちは十分に適切な反応を示した。
書き手がいるところでは、読み手は待たされることになる。作家が書くまで。
読者が複数いる場合、読者は自分の変数を交渉する必要があります。
1人の転生者が変数の内容を変更している間、他の転生者は待機しています。
たとえ現時点では他の化物がなくても、リソースのロックはシステムコアに行くので、高価な操作になります。
すべての化身が取引環境を追い求めてからが本番です。同時に取引を開始するとは、神業です。
全体として、若者は言われたことに耳を傾けないのです。繰り返しています。事例を交えて解説付き。10年以上連続で
以上のことから理解されるように、問題は書き手と読み手のシンクロニシティそのものであり、それにはコストがかかるということです。
シンクロなし、問題なし。うーん、簡潔な賢さ、最適化の面では。スラブおじさんの説明ありがとうございます ))
私も恨まないで下さいね。私はマジシャンではありません、勉強中です ))
ただ、リアルタイムシステムでは、すべてがマルチタスクモードで動作し、同期手順が主なツールであることを理解していません。
OSRTもブレーキシステムなんですね。論理的とは思えませんね。ただし、納期、レイテンシー、ジッターもある。
また、オブジェクトモデルについては、ここにレースがあると言えますか？あるいは、そのようなアプローチの結果、どのようなことが起こりうるのでしょうか。
https://www.mql5.com/ru/code/31306
あるいは、そのようなアプローチの結果、どのようなことが起こりうるでしょうか。
https://www.mql5.com/ru/code/31306
それにどんな価値があるのだろう？
ニコライさん、こんにちは。まあ、そうなんですけどね。
しかし、スラバが語るシンクロと同じ問題、つまり無理なブレーキがかからないか。
それとも、問題はないのでしょうか？))優先順位と同期させるより、非同期モデルを使わない方が楽なのかも？))
ニコライさん、こんにちは。それはそうですね。
しかし、Slavaが語る同期の場合と同じ問題、つまり理不尽なブレーキがかかるのではありませんか。
それとも、問題はないのでしょうか？))優先順位と同期させるより、非同期モデルを使わない方が楽なのかも？))
私は専門家ではありません。重要度は，他のタスクの開始が現在のタスクの終了に依存するかどうかで決まる．他の基準は二の次となる．一般的に、優先順位をつけたアルゴリズムをその場で変更することは難しく、最も悲しいことに不可能です。良い面では、疑問が生じる前に、開発者から何らかの説明が欲しいところです。難しいことではありますが、環境整備において正しい目標です。