바로 쓴 것 같습니다. 터미널 최적화에는 두 개의 비활성화된 에이전트가 있습니다. 활성화된 각 에이전트는 커널을 사용합니다.
수동 비활성화(또는 에이전트의 다른 구성)에 대해서는 명시적으로 언급되어 있지 않으며 이 뉘앙스는 여전히 우회됩니다. 이것이 바로 제가 얼마나 많은 병렬 작업이 자동화되는지에 대한 질문이있는 이유입니다. 저는 주제와 블로그 설명에서 완전 자동화가 완료되었다고 순진하게 생각했습니다.
제가 파일 작업을 잠그는 것으로 공식화한 것이 바로 LockWaiting입니다. 클립보드를 포함한 리소스에 액세스하는 데 잠금을 사용할 수 있다는 것은 분명합니다. 용어 혼동입니다.
추신. 내가 뭔가 오해하고있을 수도 있지만 클립 보드에 대한 독점 액세스 만 필요한 경우 동일한 잠금 (주기적 검사가있는 루프)이 클립 보드 자체의 기능 (소스 코드에 이미 언급 된 OpenClipboard)에서 수행하는 것이 더 논리적입니다.
수동으로 에이전트를 비활성화(또는 다른 방식으로 구성)하는 것에 대해서는 명시적으로 언급되어 있지 않으며, 그 뉘앙스가 여전히 우회되어 있습니다. 이것이 바로 제가 얼마나 많은 병렬 작업이 자동화되었는지에 대한 의문이 드는 이유입니다. 저는 순진하게도 주제와 블로그 설명을 보고 완전 자동화가 완료된 것으로 생각했습니다.
MQ 측의 완전 자동화. 어떤 기계에서든 하나의 터미널로 작업하더라도 지연 없이 작업할 수 있도록 1~2개의 에이전트를 끄고 작업합니다.
터미널1(최적화): 에이전트 3000-3017 - 활성화, 30018-3019 - 비활성화. 다른 모든 터미널은 첫 번째 터미널의 전체 복사본이기 때문에 모든 터미널에서 마찬가지입니다. 수동 설정은 하지 않습니다.
터미널 2 - 단일 패스의 경우.
두 가지 시나리오.
먼저 터미널1에서 최적화를 실행했고 3000-3017이 켜져 있었습니다. 그런 다음 터미널2에서 싱글 패스 - 3018이 작동합니다.
먼저 터미널2에서 싱글을 실행했더니 3000이 켜졌습니다. 그런 다음 터미널1에서 최적화를 실행하여 3001-3018을 실행했습니다.
모든 것이 MQ 측에서 자동화됩니다. 확인하는 데 1분이면 충분합니다. 대화에는 훨씬 더 많은 시간이 걸렸습니다.
수동 구성이 없습니다. 상담원에게 아무것도 할 수 없으며 행동이 변경되지 않습니다. 놀랍습니다.
"병렬 테스터로 작업할 때 발생할 수 있는 충돌을 피하기 위해서"라고 명시되어 있습니다. 실제로 수행되는 것은 에이전트의 수동 구성이기 때문에 이 문구는 코어의 맥락에서 오해의 소지가 있습니다. 어떤 이유에서인지 포트 할당을 코어와 계속 연관시키고 있습니다. 포트는 겹칠 수 없지만 커널(프로세스)은 겹칠 수 있으며, 이는 사전 구성에 따라 달라집니다. 병렬 프로세스 간의 자동 충돌 해결에 대한 개념이 다른 것 같습니다.
소스 변경 사항에서 클립보드에 어떤 작업이 수행된 것을 보지 못했습니다.
최적화를 실행하면 사용 가능한 모든 코어가 한꺼번에 사용되지 않나요? 단일 테스트가 어떻게 최적화에서 하나의 코어를 "제거"했는지 이해가 되지 않습니다(실제로 MT 최적화 에이전트 2개도 비활성화된 것으로 표시되어 있습니다).
제가 바로 쓴 것 같습니다. 터미널 최적화에는 두 개의 비활성화 된 에이전트가 있습니다. 활성화된 각 에이전트는 코어를 사용합니다.
바로 쓴 것 같습니다. 터미널 최적화에는 두 개의 비활성화된 에이전트가 있습니다. 활성화된 각 에이전트는 커널을 사용합니다.
수동 비활성화(또는 에이전트의 다른 구성)에 대해서는 명시적으로 언급되어 있지 않으며 이 뉘앙스는 여전히 우회됩니다. 이것이 바로 제가 얼마나 많은 병렬 작업이 자동화되는지에 대한 질문이있는 이유입니다. 저는 주제와 블로그 설명에서 완전 자동화가 완료되었다고 순진하게 생각했습니다.
제가 파일 작업을 잠그는 것으로 공식화한 것이 바로 LockWaiting입니다. 클립보드를 포함한 리소스에 액세스하는 데 잠금을 사용할 수 있다는 것은 분명합니다. 용어 혼동입니다.
추신. 내가 뭔가 오해하고있을 수도 있지만 클립 보드에 대한 독점 액세스 만 필요한 경우 동일한 잠금 (주기적 검사가있는 루프)이 클립 보드 자체의 기능 (소스 코드에 이미 언급 된 OpenClipboard)에서 수행하는 것이 더 논리적입니다.
수동으로 에이전트를 비활성화(또는 다른 방식으로 구성)하는 것에 대해서는 명시적으로 언급되어 있지 않으며, 그 뉘앙스가 여전히 우회되어 있습니다. 이것이 바로 제가 얼마나 많은 병렬 작업이 자동화되었는지에 대한 의문이 드는 이유입니다. 저는 순진하게도 주제와 블로그 설명을 보고 완전 자동화가 완료된 것으로 생각했습니다.
MQ 측의 완전 자동화. 어떤 기계에서든 하나의 터미널로 작업하더라도 지연 없이 작업할 수 있도록 1~2개의 에이전트를 끄고 작업합니다.
터미널1(최적화): 에이전트 3000-3017 - 활성화, 30018-3019 - 비활성화. 다른 모든 터미널은 첫 번째 터미널의 전체 복사본이기 때문에 모든 터미널에서 마찬가지입니다. 수동 설정은 하지 않습니다.
터미널 2 - 단일 패스의 경우.
두 가지 시나리오.
추신. 내가 뭔가 오해하고있을 수도 있지만 클립 보드에 대한 예외적 인 액세스 만 필요한 경우 클립 보드 자체의 기능 (소스에서 이미 언급 한 OpenClipboard)에 대해 동일한 잠금 (주기적 확인이있는 루프)을 수행하는 것이 더 논리적 일 것입니다.
그런 해결책에는 논리가 보이지 않습니다.
MQ 측의 완전 자동화. 어떤 머신에서든 하나의 단말기로 작업하더라도 1~2명의 에이전트를 꺼서 지연 없이 작업할 수 있도록 합니다.
터미널1(최적화): 에이전트 3000-3017 - 활성화, 30018-3019 - 비활성화. 다른 모든 터미널은 첫 번째 터미널의 전체 복사본이기 때문에 모든 터미널에서 마찬가지입니다. 수동 설정이 이루어지지 않습니다.
터미널2 - 단일 패스의 경우.
두 가지 시나리오.
이 설명이 블로그에 있었다면 의문의 여지가 없었을 것입니다. 다시 말하지만, 이 설명은 자동화가 아닌 에이전트의 수동 구성을 의미합니다. 확인할 것이 없습니다.
이 설명이 블로그에 있었다면 의문의 여지가 없었을 것입니다. 다시 말하지만 이 설명은 자동화가 아닌 상담원의 수동 구성을 의미합니다. 확인할 것이 없습니다.
수동 구성이 없습니다. 상담원에게 아무것도 할 수 없으며 동작이 변경되지 않습니다. 놀랍군요.
수동 구성이 없습니다. 상담원에게 아무것도 할 수 없으며 행동이 변경되지 않습니다. 놀랍습니다.
"병렬 테스터로 작업할 때 발생할 수 있는 충돌을 피하기 위해서"라고 명시되어 있습니다. 실제로 수행되는 것은 에이전트의 수동 구성이기 때문에 이 문구는 코어의 맥락에서 오해의 소지가 있습니다. 어떤 이유에서인지 포트 할당을 코어와 계속 연관시키고 있습니다. 포트는 겹칠 수 없지만 커널(프로세스)은 겹칠 수 있으며, 이는 사전 구성에 따라 달라집니다. 병렬 프로세스 간의 자동 충돌 해결에 대한 개념이 다른 것 같습니다.
"병렬 테스터로 작업할 때 발생할 수 있는 충돌을 피하기 위해서"라고 명시되어 있습니다. 실제로는 에이전트의 수동 구성이 이루어지기 때문에 이 문구는 커널의 맥락에서 오해의 소지가 있습니다.
"우회"라는 단어를 잘못 해석하셨습니다. 이 문제는 여러 단말기에서 동시에 클립보드로 작업할 때 발생합니다. 예전에는 한 터미널의 작업이 실수로 다른 터미널에 들어갈 수 있었습니다. 이제는 제외됩니다.
MTTester.mqh에서 다음과 같은 변경 사항을 사용할 수 있습니다.
때로는 업무용 단말기에서도 동일한 작업을 수행해야 하는 경우가 있습니다. 이 작업의 자동화는 아래 예제에 나와 있습니다.
유사한 스크립트 RunMe.mq5를 실행하여 각 터미널에서 데이터를 수집해야 합니다.
이렇게 하면 됩니다.
결과적으로 한 번의 클릭으로 모든 터미널에서 데이터를 수집했습니다. 필요한 터미널(휴대용)에서 EX5를 실행하는 MTTESTER::RunEX5 덕분입니다.