[ARCHIVE]フォーラムを乱立させないために、どんなルーキーの質問でも。プロフェッショナルの皆さん、通り過ぎないでください。あなたなしではどこにも行けない - 5. - ページ 383 1...376377378379380381382383384385386387388389390...432 新しいコメント Vadim Zhunko 2013.06.02 09:47 #3821 Integer: 1.仮定からではなく、実験結果からです。ちなみに、P378のあなたの実験によって確認されています。2.378ページのコードでは、アトミックアクセスしかできません。タスクは実行のためにキューに入れられない。あるタスクが非常に長い間実行されないということも起こり得ます。 キューはシステムによって作成されます。注文を保証するものではありません。実行されるまでに時間がかかる場合があります。この欠陥アルゴリズムには、共有リソースへのアクセスの特別な順序を意味する別の方法があるのでしょうか?違うチャートのティックがいつ来るか、TSのシグナルがいつ来るか、などわからないのでは?では、共有資源にアクセスする順番にどんな違いがあるのでしょうか。このアルゴリズムでモジュールが保留になっていれば、正しい(待たせる)ことになります。しかし、アルゴリズムを組み立てるという意味では正しくありません。リヒターを読む。彼はすでにすべてを正しく描写しています。 Dmitry Fedoseev 2013.06.02 10:01 #3822 Zhunko:1.システムによってキューがキューイングされている。2.実行順序を保証するものではありません。実行に時間がかかる場合があります。 3.この欠陥アルゴリズムには、共通資源をアドレスする特別な順序を意味する別の方法があるのでしょうか? 4.異なるチャートのティックがいつ来るか、TSのシグナルがいつ来るか、などわからないのでは? 5.では、共通リソースにアクセスする順番にどんな違いがあるのでしょうか?このアルゴリズムでモジュールが保留になっていれば、正しい(待たせる)ことになります。しかし、アルゴリズムを組み立てるという意味では正しくありません。6.リヒターを読む。彼はすでに正しい道を述べている。 第2ラウンドを目指そう1.どのタスクが実際に実行され、どのタスクがタスク自体の中で拒否されたのか、システムにはわからないのです。つまり、システムから見ればタスクは終了しているが、1つのタスクだけを残して残りをブロックしたため、我々の視点では1つのタスクだけが終了していることになる。ですから、定期的にタスクの優先順位を確認することが私たちの仕事です。1 и 2.行列はできているが、順番がつけられていない)))つまり、並んでいるわけではなく、アトミックアクセスのみ提供されているわけです。3.なぜダメなの?すべてはプログラマーの手に委ねられているのです。4.すべてはプログラマーの手に委ねられているのです。5.立っていたら。しかし、それは成り立たない。タスクはキューに入れず、実行するかしないかだけです。次のロック(ティック)でも同じで、純粋にボールから...誰が先に獲得するかは不明で、残りはアウトオブバウンズとなる。6.なぜ?このように、スマートな本を読めば必ず役に立つというわけではありません。読んでいるようで、こちらの言っていることが理解できていない。読んではいないが、理解できた。 Vadim Zhunko 2013.06.02 10:14 #3823 Integer: もう一度、確認しましょう。1.どのタスクが実際に完了し、どのタスクがタスク自体の中で拒否されたのか、システムにはわからないのです。つまり、システムから見ればタスクは完了しているのですが、1つのタスクだけを残して他をブロックしているので、私たちから見れば1つのタスクしか完了していないのです。ですから、定期的にタスクの優先順位を確認することが私たちの仕事です。1 и 2.行列はできているが、順番がつけられていない)))つまり、並んでいるわけではなく、アトミックアクセスのみ提供されているわけです。3.なぜダメなの?すべてはプログラマーの手に委ねられているのです。4.すべてはプログラマーの手に委ねられているのです。5.もしそうならしかし、そうではありません。タスクはキューに入れられるのではなく、実行されるかどうかだけです。次のロック(ティック)では、同じようにボールから純粋に...誰が先に獲得するかは不明で、残りはボロンの後ろです。6.なぜ?このように、スマートな本を読めば必ず役に立つというわけではありません。読んでいるようで、こちらの言っていることが理解できていない。読んではいないが、理解できた。 それは、複雑なコードに対するあなたのこだわりです。単純化するのではなく、複雑なコードをねじ曲げてキューを壊してしまうのです。私もリヒテルはずっと読みたくないと思っていました。でも、とにかく読みました。マルチスレッドアプリケーションの構築のルールは簡単です。メインはシンプルにすることです。これが、リヒターからの結論である。そうでなければ、書くことよりもデバッグに多くの時間を費やすことになります。ちなみに、私はまだマルチスレッドのアプリケーションのデバッグをしたことがないんです。すべてがすぐに機能しました。 Dmitry Fedoseev 2013.06.02 10:20 #3824 Zhunko:これは複雑なコードに対するあなたのこだわりです。単純化するのではなく、複雑なコードをねじ曲げてキューを壊してしまうのです。私もリヒテルはずっと読みたくないと思っていました。でも、とにかく読みました。マルチスレッドアプリケーションの構築のルールは簡単です。メインはシンプルにすることです。これが、リヒターからの結論である。そうでなければ、書くことよりもデバッグに多くの時間を費やすことになります。ちなみに、私はまだマルチスレッドのアプリケーションのデバッグをしたことがありません。すべてが一度にうまくいきました。 どのように複雑なのですか?複雑なコードとは?タスクに必要な最低限のものです。そして、あなたのアプローチはヌーベルバーグです。偶然の効果に頼るのではなく、すべてが確実に 機能しなければならないのです。リヒターと何の関係があるんだ?マルチスレッドとどう関係があるのですか?この話の発端となった元の問題を思い出してください。 Dimka-novitsek 2013.06.02 10:36 #3825 ヒントを教えてください。Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " ,GlobalVariableGet("Profit_pomnim") is not compiling; Vadim Zhunko 2013.06.02 10:37 #3826 Dimka-novitsek: ヒントを教えてください。Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim") is not compiling; 最後に括弧がない。 Dimka-novitsek 2013.06.02 10:39 #3827 あ、ありがとうございます!!!!すみません、そして間違いなくブラケットはありません。すぐには見抜けなかった。 Dmitry Fedoseev 2013.06.02 10:39 #3828 Dimka-novitsek: ヒントを教えてください。Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim") is not compiling; 最後にもう一つ閉じ括弧が必要です。そんな問題は自分で解決しなければならない。コンパイラは、エラーに関するヒントを生成します。ブラケットにも気を配る必要があります。オープニングを書いたら、クロージングも書いて、その間に。 Vadim Zhunko 2013.06.02 10:45 #3829 Integer: 何が大変なんだ?どんな複雑なコード?これはタスクが必要とする最小限のものです。そして、あなたのアプローチはヌーベル・アプローチです。何をするにしても、偶然の効果に頼るのではなく、確実に 動作することが保証 されている必要があります。リヒターと何の関係があるんだ?マルチスレッドシステムとの関係は?この話の発端となった元の問題を思い出してください。 いいよ、好きなように書けば。説得するつもりはない。できることはすべて話しました。本来の課題は、預け入れサイズを参照するための同期をとることでした。私が書いたコードで完璧に解決しました。すべては思いのまま。リソースを参照する時間を最小限に抑えながら すべてのモジュールは、一部の例外を除き、リクエストとほぼ同じ順序で処理されます。どっちがどうでもいいんだよ。あなたのために特別に強調します。これはマルチスレッドアプリケーションのルールの1つです。実行に時間がかかるスレッドがあれば、それをキューに入れる必要があり、それが重要なのですが、それはアルゴリズムに欠陥があるのです。やり直しをしなければならない。そんな書き方ではダメです。何でもやっていいんですけどね。書く... Dmitry Fedoseev 2013.06.02 10:52 #3830 Zhunko:1.いいよ、好きなように書いて。説得するつもりはない。できることはすべて話しました。2.当初は、入金サイズを参照するための同期をとることが課題でした。 私が書いたコードで完璧に解決しました。すべては思いのまま。リソースを参照する時間を最小限に抑えながら すべてのモジュールは、リクエストとほぼ同じ順序で処理されます。4.あなたのために特別に強調します。これはマルチスレッドアプリケーションのルールの1つです。実行に時間がかかるスレッドがあれば、それをキューに入れる必要があり、それが重要なのですが、これは間違ったアルゴリズムなのです。やり直しをしなければならない。そんな書き方ではダメです。何でもやっていいんですけどね。書く... 1.質問はなかったよ、自分の使命を甘く見るなよ。2.好きな言葉は「シンクロニシティ」?それは、並列タスクを順次実行することのバツだった。3.解決しますが、完璧ではありません。Nuber - lamerメソッドで解決。4.クックックッ、起きろ! 1...376377378379380381382383384385386387388389390...432 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
1.仮定からではなく、実験結果からです。ちなみに、P378のあなたの実験によって確認されています。
2.378ページのコードでは、アトミックアクセスしかできません。タスクは実行のためにキューに入れられない。あるタスクが非常に長い間実行されないということも起こり得ます。
キューはシステムによって作成されます。注文を保証するものではありません。実行されるまでに時間がかかる場合があります。この欠陥アルゴリズムには、共有リソースへのアクセスの特別な順序を意味する別の方法があるのでしょうか?違うチャートのティックがいつ来るか、TSのシグナルがいつ来るか、などわからないのでは?では、共有資源にアクセスする順番にどんな違いがあるのでしょうか。このアルゴリズムでモジュールが保留になっていれば、正しい(待たせる)ことになります。しかし、アルゴリズムを組み立てるという意味では正しくありません。
リヒターを読む。彼はすでにすべてを正しく描写しています。
1.システムによってキューがキューイングされている。2.実行順序を保証するものではありません。実行に時間がかかる場合があります。
3.この欠陥アルゴリズムには、共通資源をアドレスする特別な順序を意味する別の方法があるのでしょうか?
4.異なるチャートのティックがいつ来るか、TSのシグナルがいつ来るか、などわからないのでは?
5.では、共通リソースにアクセスする順番にどんな違いがあるのでしょうか?このアルゴリズムでモジュールが保留になっていれば、正しい(待たせる)ことになります。しかし、アルゴリズムを組み立てるという意味では正しくありません。
6.リヒターを読む。彼はすでに正しい道を述べている。
第2ラウンドを目指そう
1.どのタスクが実際に実行され、どのタスクがタスク自体の中で拒否されたのか、システムにはわからないのです。つまり、システムから見ればタスクは終了しているが、1つのタスクだけを残して残りをブロックしたため、我々の視点では1つのタスクだけが終了していることになる。ですから、定期的にタスクの優先順位を確認することが私たちの仕事です。
1 и 2.行列はできているが、順番がつけられていない)))つまり、並んでいるわけではなく、アトミックアクセスのみ提供されているわけです。
3.なぜダメなの?すべてはプログラマーの手に委ねられているのです。
4.すべてはプログラマーの手に委ねられているのです。
5.立っていたら。しかし、それは成り立たない。タスクはキューに入れず、実行するかしないかだけです。次のロック(ティック)でも同じで、純粋にボールから...誰が先に獲得するかは不明で、残りはアウトオブバウンズとなる。
6.なぜ?このように、スマートな本を読めば必ず役に立つというわけではありません。読んでいるようで、こちらの言っていることが理解できていない。読んではいないが、理解できた。
もう一度、確認しましょう。
1.どのタスクが実際に完了し、どのタスクがタスク自体の中で拒否されたのか、システムにはわからないのです。つまり、システムから見ればタスクは完了しているのですが、1つのタスクだけを残して他をブロックしているので、私たちから見れば1つのタスクしか完了していないのです。ですから、定期的にタスクの優先順位を確認することが私たちの仕事です。
1 и 2.行列はできているが、順番がつけられていない)))つまり、並んでいるわけではなく、アトミックアクセスのみ提供されているわけです。
3.なぜダメなの?すべてはプログラマーの手に委ねられているのです。
4.すべてはプログラマーの手に委ねられているのです。
5.もしそうならしかし、そうではありません。タスクはキューに入れられるのではなく、実行されるかどうかだけです。次のロック(ティック)では、同じようにボールから純粋に...誰が先に獲得するかは不明で、残りはボロンの後ろです。
6.なぜ?このように、スマートな本を読めば必ず役に立つというわけではありません。読んでいるようで、こちらの言っていることが理解できていない。読んではいないが、理解できた。
それは、複雑なコードに対するあなたのこだわりです。単純化するのではなく、複雑なコードをねじ曲げてキューを壊してしまうのです。
私もリヒテルはずっと読みたくないと思っていました。でも、とにかく読みました。マルチスレッドアプリケーションの構築のルールは簡単です。メインはシンプルにすることです。これが、リヒターからの結論である。そうでなければ、書くことよりもデバッグに多くの時間を費やすことになります。ちなみに、私はまだマルチスレッドのアプリケーションのデバッグをしたことがないんです。すべてがすぐに機能しました。
これは複雑なコードに対するあなたのこだわりです。単純化するのではなく、複雑なコードをねじ曲げてキューを壊してしまうのです。
私もリヒテルはずっと読みたくないと思っていました。でも、とにかく読みました。マルチスレッドアプリケーションの構築のルールは簡単です。メインはシンプルにすることです。これが、リヒターからの結論である。そうでなければ、書くことよりもデバッグに多くの時間を費やすことになります。ちなみに、私はまだマルチスレッドのアプリケーションのデバッグをしたことがありません。すべてが一度にうまくいきました。
どのように複雑なのですか?複雑なコードとは?タスクに必要な最低限のものです。そして、あなたのアプローチはヌーベルバーグです。偶然の効果に頼るのではなく、すべてが確実に 機能しなければならないのです。
リヒターと何の関係があるんだ?マルチスレッドとどう関係があるのですか?この話の発端となった元の問題を思い出してください。
ヒントを教えてください。Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim") is not compiling;
ヒントを教えてください。Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim") is not compiling;
何が大変なんだ?どんな複雑なコード?これはタスクが必要とする最小限のものです。そして、あなたのアプローチはヌーベル・アプローチです。何をするにしても、偶然の効果に頼るのではなく、確実に 動作することが保証 されている必要があります。
リヒターと何の関係があるんだ?マルチスレッドシステムとの関係は?この話の発端となった元の問題を思い出してください。
いいよ、好きなように書けば。説得するつもりはない。できることはすべて話しました。
本来の課題は、預け入れサイズを参照するための同期をとることでした。私が書いたコードで完璧に解決しました。すべては思いのまま。リソースを参照する時間を最小限に抑えながら すべてのモジュールは、一部の例外を除き、リクエストとほぼ同じ順序で処理されます。どっちがどうでもいいんだよ。
あなたのために特別に強調します。これはマルチスレッドアプリケーションのルールの1つです。実行に時間がかかるスレッドがあれば、それをキューに入れる必要があり、それが重要なのですが、それはアルゴリズムに欠陥があるのです。やり直しをしなければならない。そんな書き方ではダメです。何でもやっていいんですけどね。書く...
1.いいよ、好きなように書いて。説得するつもりはない。できることはすべて話しました。
2.当初は、入金サイズを参照するための同期をとることが課題でした。
私が書いたコードで完璧に解決しました。すべては思いのまま。リソースを参照する時間を最小限に抑えながら すべてのモジュールは、リクエストとほぼ同じ順序で処理されます。
4.あなたのために特別に強調します。これはマルチスレッドアプリケーションのルールの1つです。実行に時間がかかるスレッドがあれば、それをキューに入れる必要があり、それが重要なのですが、これは間違ったアルゴリズムなのです。やり直しをしなければならない。そんな書き方ではダメです。何でもやっていいんですけどね。書く...
1.質問はなかったよ、自分の使命を甘く見るなよ。
2.好きな言葉は「シンクロニシティ」?それは、並列タスクを順次実行することのバツだった。
3.解決しますが、完璧ではありません。Nuber - lamerメソッドで解決。
4.クックックッ、起きろ!