비동기 및 동기라는 용어를 잘못 이해하고 있습니다. 함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다. 반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다. 지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다. 단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다. "데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다. 일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
알랭 벌리앙 :
아니요. Get 메서드는 동기식이지만 그룹화하여 동시에 실행할 수 있으므로 1 Get 또는 100 메서드를 호출하는 것은 거의 동일합니다.
set 메서드는 비동기식이지만 효율성을 높이기 위해 함께 그룹화할 수도 있습니다.
따라서 항상 "Get/Set/Get/Set/Get/Set"보다는 "Set Calls Together"와 "Receive Calls Together"를 그룹화하는 것이 좋습니다.
함수가 실행되는 동안 호출 스레드가 차단되지 않으면 비동기식 호출이 더 효율적이지만 Get과 Set을 혼합하면 이러한 이점을 잃게 됩니다.
번역에도 불구하고 이것이 도움이되기를 바랍니다.
알렉세이 마브린 :
내가 이해하는 것처럼 Get은 동기식입니다. 요청한 결과를 반환합니다. 그러나 대기열에 비동기 세트가 있으면 동기화해야 합니다.
대기열에 Get만 있는 경우 지연이 없습니다.
감사합니다. 슬슬 움직이기 시작합니다.
그러한 지연에 대한 진정한 그림이 이제 나타나고 있습니다.
내가 이해한 대로(잘못된 경우 수정해 주세요):
메인 스레드에서 Get 메소드가 호출되면 차트 자체의 스레드에 요청이 이루어지며 이는 메인 스레드와 병렬로 실행됩니다. 하지만 차트 쓰레드는 메인 쓰레드에서 직접 Set 메소드에 의해 제어되고, 메인 쓰레드는 이미 차트의 현재 특성을 알고 있어야 하지만 차트 쓰레드의 현재 상태만 모르고 마지막 쓰레드가 명령이 실행되었습니다. 이것이 이전의 모든 명령이 처리되었는지 확인하기 위해 이 요청이 발생하는 이유입니다. 그리고 Get 메서드는 동기식이므로 병렬 차트 스트림에서 응답이 올 때까지 기다립니다. 이것이 지연의 원인입니다.
내가 혼란스럽지 않다면 다음과 같은 질문이 생깁니다.
병렬 스레드가 명령이 실행되었음을 주 스레드에 보고할 수 없는 이유는 무엇입니까? 그러면 주 스레드가 명령을 완료된 것으로 표시하고 내부 차트 특성 테이블을 업데이트할 것입니다. 요청 시 Get은 요청 및 병렬 흐름 없이 이 테이블의 데이터를 발행합니다. 또한, 차트의 현재 상태를 이해하기 위해 차트의 병렬 스레드에 아직 실행되지 않은 명령이 있거나 모든 명령이 실행되었음을 나타내는 플래그를 보낼 수 있습니다. 이 계획을 사용하면 지연이 없습니다.
거의 유사한 메커니즘이 내 iCanvas 클래스에서 구현됩니다.
다음은 캔버스의 픽셀 좌표를 차트의 시간 및 가격과 연결하는 매우 느린 ChartXYToTimePrice 함수 가 있고 해당 아날로그 XYToTimePrice 함수가 생성되어 CHARTEVENT_CHART_CHANGE 이벤트가 발생하고 이 정적 테이블 차트 매개변수의 데이터를 기반으로 요청된 매개변수를 계산합니다.
나는 유추를 사용하려고 노력할 것입니다. 만약 그것이 효과가 없다면, 그렇게 하십시오. 모두 매우 과장되고 사실이 아니지만 여전히 그렇습니다.
당신이 있습니다. 페인트를 결정하고 아티스트에게 가져 오는 고객이 있고, 가져온 페인트를 사용하여 캔버스에 그리는 아티스트가 있습니다. 페인트를 가져온 후에는 직장, 집, 공부, .... 또한 언제든지 작가에게 찾아가 작품의 결과물을 확인할 수 있다. 그러나 그 순간에 화가가 그림을 그리고 있는 현장을 구경하러 오면 작업이 끝날 때까지 기다려야 합니다.
가장 최적의 상호 작용 방법은 필요한 모든 페인트를 예술가에게 가져와 그림을 그리도록 명령한 다음 작업을 진행하는 것입니다. 마지막에 필요한 경우 아티스트에게 필요한 만큼 여러 번 검사를 받으러 오십시오. 캔버스에 대한 액세스는 무료입니다.
가장 비최적의 상호 작용 방법은 한 번에 하나씩 아티스트에게 페인트를 가져와 즉시 결과를 요구하고 매번 아티스트가 작업을 완료할 때까지 기다리는 것입니다.
2009 빌드와 비교하여 2485의 문제는 무엇입니까? 아티스트가 당신에게 더 가까이 이동했고, 검사를 위한 이동 시간이 줄어든 것도 장점입니다. 그러나 작가는 많은 시간을 '아르바이트'로 보내기 시작했다. 예전에는 같은 빈도로 '아르바이트'를 했지만, 지금은 작가의 '아르바이트'를 하기 위해 너무 오래 기다려야 한다.
가장 최적의 상호 작용 방법은 필요한 모든 페인트를 예술가에게 가져와 그림을 그리도록 명령한 다음 작업을 진행하는 것입니다. 마지막에 필요한 경우 아티스트에게 필요한 만큼 여러 번 검사를 받으러 오십시오. 캔버스에 대한 액세스는 무료입니다.
내 생각에 가장 좋은 것은 다음 그림을 완성하는 즉시 완성된 특정 작업을 고객이 볼 수 있는 웹사이트에 즉시 표시하고 다음 그림을 완성해야 한다는 데 예술가와 동의하는 것입니다. 그의 현재 상태를 나타냅니다 - 그는 아르바이트로 바쁘거나 자유입니다. 그러면 고객은 작가를 방문하지 않고 어떤 그림이 준비되고 어떤 그림이 준비되지 않았는지, 현재 예술가가 바쁘거나 비어 있는지를 알고 다음 작업을 보낼 수 있습니다. 그리고 검사에 헛되이 매달릴 필요가 없습니다. 이것은 고객과 예술가 모두에게 시간과 신경을 절약할 것입니다.
1) 제가 생각하는 가장 최적의 방법은 작가님의 의견에 동의하는 것이며, 2) 다음 사진을 마치자마자 3) 그런 다음 그는 고객이 볼 수 있는 웹사이트에 완료된 특정 작업을 즉시 표시합니다. 4) 또한 그가 아르바이트로 바쁘거나 자유로울지 여부에 관계없이 사이트에 자신의 현재 상태를 표시해야 한다는 데 동의합니다. 5) 그러면 고객은 .... 아티스트가 현재 바쁜지 또는 한가한지 알고 다음 작업을 보낼 수 있습니다. 6) 검사에 헛되이 매달릴 필요가 없습니다. 이것은 고객과 예술가 모두에게 시간과 신경을 절약할 것입니다.
1) 아티스트는 당신의 계획을 모르고 당신도 미래를 모릅니다... 2) 그림이 없고, 모든 조작과 "아르바이트"가 진행되고 있는 하나의 캔버스가 있습니다. 3) 유추의 본질과 유비가 필요한 이유를 이해하지 못하는 주요 소스와 관련이 없는 유추에 프로세스를 도입하는 것. 4) 예술가는 미래를 알지 못하며, 점검을 받으러 오면 여행 중에 그의 신분이 백 번 바뀔 수 있습니다. 5) 물감은 언제든지 가지고 오실 수 있으며, 작가의 신분과 고용 여부에 관계없이 항상 동일한 시간이 소요됩니다. 6) 또 비유가 무엇인지, 비유가 왜 필요한지 이해하지 못함...
플레이 단계:
이 작품에 대해 감사하다는 말을 하지 않을 수 없습니다! 바라건대, 다른 버그들도 언젠가는 비슷한 것을 얻게 될 것입니다.
울지 마십시오. 오래전에 이미 대답 했습니다.
불행히도 배기 가스는 0 일뿐만 아니라 음수였습니다 ...
왜 부정적인지...
글쎄, 나는 첫 번째를 따라잡지 못했다. 글쎄, 나는 두 번째를 따라잡지 못했지만 세 번째를 따라잡았다.
글쎄, 내가 너무 빡빡 하면. 이것은 당신의 잘못이 아닙니다.
그러므로 화를 내지 마십시오, Sergey.
비동기 및 동기라는 용어를 잘못 이해하고 있습니다.
함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다.
반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다.
지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다.
단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다.
"데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다.
일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
아니요. Get 메서드는 동기식이지만 그룹화하여 동시에 실행할 수 있으므로 1 Get 또는 100 메서드를 호출하는 것은 거의 동일합니다.
set 메서드는 비동기식이지만 효율성을 높이기 위해 함께 그룹화할 수도 있습니다.
따라서 항상 "Get/Set/Get/Set/Get/Set"보다는 "Set Calls Together"와 "Receive Calls Together"를 그룹화하는 것이 좋습니다.
함수가 실행되는 동안 호출 스레드가 차단되지 않으면 비동기식 호출이 더 효율적이지만 Get과 Set을 혼합하면 이러한 이점을 잃게 됩니다.
번역에도 불구하고 이것이 도움이되기를 바랍니다.
내가 이해하는 것처럼 Get은 동기식입니다. 요청한 결과를 반환합니다. 그러나 대기열에 비동기 세트가 있으면 동기화해야 합니다.
대기열에 Get만 있는 경우 지연이 없습니다.
감사합니다. 슬슬 움직이기 시작합니다.
그러한 지연에 대한 진정한 그림이 이제 나타나고 있습니다.
내가 이해한 대로(잘못된 경우 수정해 주세요):
메인 스레드에서 Get 메소드가 호출되면 차트 자체의 스레드에 요청이 이루어지며 이는 메인 스레드와 병렬로 실행됩니다. 하지만 차트 쓰레드는 메인 쓰레드에서 직접 Set 메소드에 의해 제어되고, 메인 쓰레드는 이미 차트의 현재 특성을 알고 있어야 하지만 차트 쓰레드의 현재 상태만 모르고 마지막 쓰레드가 명령이 실행되었습니다. 이것이 이전의 모든 명령이 처리되었는지 확인하기 위해 이 요청이 발생하는 이유입니다. 그리고 Get 메서드는 동기식이므로 병렬 차트 스트림에서 응답이 올 때까지 기다립니다. 이것이 지연의 원인입니다.
내가 혼란스럽지 않다면 다음과 같은 질문이 생깁니다.
병렬 스레드가 명령이 실행되었음을 주 스레드에 보고할 수 없는 이유는 무엇입니까? 그러면 주 스레드가 명령을 완료된 것으로 표시하고 내부 차트 특성 테이블을 업데이트할 것입니다. 요청 시 Get은 요청 및 병렬 흐름 없이 이 테이블의 데이터를 발행합니다. 또한, 차트의 현재 상태를 이해하기 위해 차트의 병렬 스레드에 아직 실행되지 않은 명령이 있거나 모든 명령이 실행되었음을 나타내는 플래그를 보낼 수 있습니다. 이 계획을 사용하면 지연이 없습니다.
거의 유사한 메커니즘이 내 iCanvas 클래스에서 구현됩니다.
다음은 캔버스의 픽셀 좌표를 차트의 시간 및 가격과 연결하는 매우 느린 ChartXYToTimePrice 함수 가 있고 해당 아날로그 XYToTimePrice 함수가 생성되어 CHARTEVENT_CHART_CHANGE 이벤트가 발생하고 이 정적 테이블 차트 매개변수의 데이터를 기반으로 요청된 매개변수를 계산합니다.
감사합니다. 슬슬 움직이기 시작합니다.
...맞아요. 그리고 Renat이 말했듯이 캐시 시스템은 mql 쪽에서 구현되어야 합니다. 아마도 이것은 플랫폼 측에서 구현될 수 있지만 가능한 가장 성능이 좋은 다중 스레드 아키텍처의 달성을 위태롭게 할 것입니다.
분명한.
이 캐시 시스템을 구현하는 방법을 이해하는 사람들에게는 훨씬 더 좋고, 그렇지 않은 사람들에게는 더 나쁩니다.
나는 유추를 사용하려고 노력할 것입니다. 만약 그것이 효과가 없다면, 그렇게 하십시오.
모두 매우 과장되고 사실이 아니지만 여전히 그렇습니다.
당신이 있습니다. 페인트를 결정하고 아티스트에게 가져 오는 고객이 있고, 가져온 페인트를 사용하여 캔버스에 그리는 아티스트가 있습니다.
페인트를 가져온 후에는 직장, 집, 공부, ....
또한 언제든지 작가에게 찾아가 작품의 결과물을 확인할 수 있다.
그러나 그 순간에 화가가 그림을 그리고 있는 현장을 구경하러 오면 작업이 끝날 때까지 기다려야 합니다.
가장 최적의 상호 작용 방법은 필요한 모든 페인트를 예술가에게 가져와 그림을 그리도록 명령한 다음 작업을 진행하는 것입니다.
마지막에 필요한 경우 아티스트에게 필요한 만큼 여러 번 검사를 받으러 오십시오. 캔버스에 대한 액세스는 무료입니다.
가장 비최적의 상호 작용 방법은 한 번에 하나씩 아티스트에게 페인트를 가져와 즉시 결과를 요구하고 매번 아티스트가 작업을 완료할 때까지 기다리는 것입니다.
2009 빌드와 비교하여 2485의 문제는 무엇입니까?
아티스트가 당신에게 더 가까이 이동했고, 검사를 위한 이동 시간이 줄어든 것도 장점입니다.
그러나 작가는 많은 시간을 '아르바이트'로 보내기 시작했다.
예전에는 같은 빈도로 '아르바이트'를 했지만, 지금은 작가의 '아르바이트'를 하기 위해 너무 오래 기다려야 한다.
분명한.
이 캐시 시스템을 구현하는 방법을 이해하는 사람들에게는 훨씬 더 좋고, 그렇지 않은 사람들에게는 더 나쁩니다.
가장 최적의 상호 작용 방법은 필요한 모든 페인트를 예술가에게 가져와 그림을 그리도록 명령한 다음 작업을 진행하는 것입니다.
마지막에 필요한 경우 아티스트에게 필요한 만큼 여러 번 검사를 받으러 오십시오. 캔버스에 대한 액세스는 무료입니다.
내 생각에 가장 좋은 것은 다음 그림을 완성하는 즉시 완성된 특정 작업을 고객이 볼 수 있는 웹사이트에 즉시 표시하고 다음 그림을 완성해야 한다는 데 예술가와 동의하는 것입니다. 그의 현재 상태를 나타냅니다 - 그는 아르바이트로 바쁘거나 자유입니다.
그러면 고객은 작가를 방문하지 않고 어떤 그림이 준비되고 어떤 그림이 준비되지 않았는지, 현재 예술가가 바쁘거나 비어 있는지를 알고 다음 작업을 보낼 수 있습니다. 그리고 검사에 헛되이 매달릴 필요가 없습니다. 이것은 고객과 예술가 모두에게 시간과 신경을 절약할 것입니다.
1) 제가 생각하는 가장 최적의 방법은 작가님의 의견에 동의하는 것이며,
2) 다음 사진을 마치자마자
3) 그런 다음 그는 고객이 볼 수 있는 웹사이트에 완료된 특정 작업을 즉시 표시합니다.
4) 또한 그가 아르바이트로 바쁘거나 자유로울지 여부에 관계없이 사이트에 자신의 현재 상태를 표시해야 한다는 데 동의합니다.
5) 그러면 고객은 .... 아티스트가 현재 바쁜지 또는 한가한지 알고 다음 작업을 보낼 수 있습니다.
6) 검사에 헛되이 매달릴 필요가 없습니다. 이것은 고객과 예술가 모두에게 시간과 신경을 절약할 것입니다.
1) 아티스트는 당신의 계획을 모르고 당신도 미래를 모릅니다...
2) 그림이 없고, 모든 조작과 "아르바이트"가 진행되고 있는 하나의 캔버스가 있습니다.
3) 유추의 본질과 유비가 필요한 이유를 이해하지 못하는 주요 소스와 관련이 없는 유추에 프로세스를 도입하는 것.
4) 예술가는 미래를 알지 못하며, 점검을 받으러 오면 여행 중에 그의 신분이 백 번 바뀔 수 있습니다.
5) 물감은 언제든지 가지고 오실 수 있으며, 작가의 신분과 고용 여부에 관계없이 항상 동일한 시간이 소요됩니다.
6) 또 비유가 무엇인지, 비유가 왜 필요한지 이해하지 못함...