1. 헛된 당신입니다. 그의 알고리즘에 대한 나의 감탄은 거기에도 표현되어 있습니다. 이것은 동일한 HRENFIX입니다. 그런 그에게 또 다른 별명이 생겼다.
스크립트 이름의 접두사에서 우리 닉네임의 첫 글자.
================
2. Dmitry, 모든 것에도 불구하고 공개 대상이 아닌 일부 비밀 알고리즘으로 비밀 문제를 해결해 주셔서 진심으로 기쁩니다.
3. 모든 것이 매우 신비롭게 보였습니다. 자랑해주셔서 감사합니다. 당신은 의심할 여지 없이 이 포럼에서 가장 멋진 프로그래머이며 아마도 전 세계에서 가장 멋진 프로그래머일 것입니다!
1. 아 네! 이것이 귀하의 코드 또는 귀하의 친구인 것으로 판명된 후. Abaldet는 가장 무가치하고 수치스러웠지만 이제 그는 즉시 유쾌해졌습니다.
2. 내가 어떤 프로그래머인지, 무엇을 알고 무엇을 할 수 있는지, 어떻게 알며 할 수 있는지, 무엇을 모르고 무엇을 할 수 없는지 - 어떻게든 스스로 알아내겠습니다.
3. 작업은 전혀 비밀이 아니며 절대적으로 명백하며 여기에서 공개적으로 정의되었습니다. 이해할 수 있는 사람은 문제 없이 즉시 이해했습니다. 나는 비밀스러운 마법의 방법이 아니라 일반적인 표준과 명시적인(세계적으로 유명한) 방법으로 해결했습니다. 여기 자랑하는 게 아니라 너 때문에 기적이라 웃는다. 당신의 과대망상증만이 당신이 이것을 이해하고 깨닫도록 허용하지 않습니다.
1. 아 네! 이것이 귀하의 코드 또는 귀하의 친구인 것으로 판명된 후. Abaldet는 가장 무가치하고 수치스러웠지만 이제 그는 즉시 유쾌해졌습니다.
2. 내가 어떤 프로그래머인지, 무엇을 알고 무엇을 할 수 있는지, 어떻게 알며 할 수 있는지, 무엇을 모르고 무엇을 할 수 없는지 - 어떻게든 스스로 알아내겠습니다.
3. 작업은 전혀 비밀이 아니며 절대적으로 명백하며 여기에서 공개적으로 정의되었습니다. 이해할 수 있는 사람은 문제 없이 즉시 이해했습니다. 나는 비밀스러운 마법의 방법이 아니라 일반적인 표준과 명시적인(세계적으로 유명한) 방법으로 해결했습니다. 여기 자랑하는 게 아니라 너 때문에 기적이라 웃는다. 당신의 과대망상증만이 당신이 이것을 이해하고 깨닫도록 허용하지 않습니다.
얘들아, 다른 데 가서 문질러! 여기 사람들은 실용적인 문제를 해결합니다. 그리고 당신은 감정으로 가지를 막습니다 ...
1. 아 네! 이것이 귀하의 코드 또는 귀하의 친구인 것으로 판명된 후. Abaldet는 가장 무가치하고 수치스러웠지만 이제 그는 즉시 유쾌해졌습니다.
2. 내가 어떤 프로그래머인지, 무엇을 알고 무엇을 할 수 있는지, 어떻게 알며 할 수 있는지, 무엇을 모르고 무엇을 할 수 없는지 - 어떻게든 스스로 알아내겠습니다.
3. 작업은 전혀 비밀이 아니며 절대적으로 명시적이며 여기에서 공개적으로 정의되었습니다. 이해할 수 있는 사람은 문제 없이 즉시 이해했습니다. 나는 비밀스러운 마법의 방법이 아니라 일반적인 표준과 명시적인(세계적으로 유명한) 방법으로 해결했습니다. 여기 자랑하는 게 아니라 너 때문에 기적이라 웃는다. 당신의 과대망상증만이 당신이 이것을 이해하고 깨닫는 것을 허용하지 않습니다.
1. 코드와 알고리즘의 차이가 느껴지시나요? 또한 알고리즘은 차트 창을 여는 것과 관련이 없습니다. 코드가 수정되었습니다. 차트가 열리는 곳은 크게 바뀌지 않았습니다. 그 당시에는 다른 선택지가 없었습니다. DLL에서 만든 여자친구에게. 더 듬직 해요.
2. 훌륭하다! 당신은 최고입니다!
3. 당신은 이것을 의미합니다:
자주 묻는 질문 :
1) 작업: 각 스크립트(EA)는 다른 모든 스크립트의 존재를 알아야 합니다.
2) 문제: 실패가 발생하면 실패한 전역의 전역이 불안정하게 멈추고 대기열이 중지됩니다.
3) 솔루션:
각 exp는 공통 접두사 + 창 핸들 + 기호라는 이름으로 1개의 전역을 구성합니다. 전역 값은 이 기호의 마지막 눈금 시간입니다. 자체 핸들이 있는 2개의 공통 글로벌(작동한 후 핸들을 기록하거나 가장 오래된 핸들인 경우 재설정)
대기열을 오름차순(핸들)으로 구성하고 가장 오래된 대기열은 두 번째 전역을 재설정합니다.
각 exp에서 우리는 세 개의 배열(구조가 없는 경우)을 만듭니다. symbol\handle\last access time\last tick time.
모든 전문가는 모두에 대해 (마지막 액세스 시간 \ 마지막 틱 시간)을 추적하고 차이가 발생하면(exp 중 하나에서 실패) 실패한 전문가의 두 전역이 삭제되고 비활성화된 것으로 간주됩니다. 배열의 셀이 제거됩니다(배열이 다시 작성됨).
대기열이 복원됩니다.
실제로 이것은 가장 활동적인 차트(자주 틱)에 있는 exp에 의해 수행됩니다.
정상적인 정의에서 각 경험치는 자체적으로 정리됩니다.
최대 건너뛰기는 1틱입니다.
추신. 그러나 일반적으로 하나의 다중 통화를 만드는 것이 좋습니다.
그래서 루스탐의 텔레파시 능력 덕분에 얻은 것이다. 이것은 가상의 문제이자 가상의 솔루션입니다. 이것이 당신의 임무와 어떤 관련이 있습니까? 당신은 그것에 대해 아무 말도하지 않았습니다. 문의해야 했습니다. 그에 대한 응답으로 모든 것을 제공하지만 실행하지 않는 건설적인 대신 완전히 맹세합니다.
2008년에도 비슷한 문제가 있었습니다. 나는 어떤 사람들처럼 비밀을하지 않을 것입니다. 어떤 일을 하고, 어떻게 결정했는지, 왜 이런 식으로 문제를 해결하는 것이 성공하지 못했다고 생각하는지 구체적인 예를 들어 말씀드리겠습니다.
===============================
작업의 초기 데이터:
1. 여러 개의 동일한 루프형 Expert Advisors가 있습니다. 저것들. 완전히 독립적인 스레드.
2. 일부 전문가가 액세스할 수 있는 8개 그룹으로 나누어진 계수 데이터베이스가 있습니다. 2GB의 데이터베이스 크기.
3. 데이터베이스는 때때로 보충됩니다. 2시간의 배수 기간 후에 보충됩니다. 처리 시간은 하루 중 시간의 다양성에 따라 다릅니다. 시간 및 프로세서 성능의 다양성에 따라 5분에서 45분 사이의 시간이 소요됩니다.
일:
1. 때문에 데이터베이스 보충에는 많은 시간이 걸리므로 보충을 담당하는 전문가는 한 명만 있으면 됩니다. 그렇지 않으면 끝날 때까지 기다릴 수 없습니다.
2. 업데이트하는 동안 데이터베이스에 대한 액세스를 비활성화해야 합니다. 전문가가 작업하는 계수 업데이트가 크게 느려지지 않도록 그룹별로 수행하십시오.
3. 현재 업데이트 중인 계수로 작업하는 Expert Advisors는 이전 계수로 작업해야 합니다.
4. 특정 그룹의 계수 업데이트 기간 동안 이 그룹으로 전환된 전문가는 단일 계수로 작업하여 이를 보고해야 합니다. 완료되면 업데이트가 새 요소로 전환되어야 합니다. 3번 항목도 마찬가지입니다.
현재 솔루션:
1. 인덱스로 구성된 전문가 식별자의 공통 대기열이 생성되었습니다.
2. 인덱스로 구성된 데이터베이스에 액세스하는 전문가의 식별자 대기열이 생성되었습니다.
3. 두 대기열 모두 공유 리소스입니다. 대기열에 대한 액세스는 단일 동기화 개체에 의해 동기화됩니다.
4. 2단계의 첫 번째 전문가를 데이터베이스 업데이트 담당 전문가로 임명합니다.
5. 또한 Rustam이 설명한 것과 거의 같습니다. DLL에서 구현하기 때문에 조금 더 쉽습니다.
식별자는 종단 간 인덱스입니다. 전문가가 제거되면 식별자가 대기열에서 제거됩니다. 재인덱싱이 수행되지 않습니다. 나머지 전문가들은 지수를 남깁니다.
새로운 전문가를 추가할 때 마지막 전문가의 인덱스가 해당 번호와 일치하지 않으면 첫 번째 무료 이전 인덱스가 할당됩니다. 그렇지 않으면 새 인덱스가 할당됩니다.
설명자 및 차트 도구에 바인딩할 필요가 없습니다. 또한 업로드 실패를 추적할 필요가 없습니다. 충돌은 없었습니다. 설령 이런 일이 일어나더라도 재앙은 아닐 것이다. Expert Advisors는 이전 계수로 계속 작업할 것입니다. 다음 업데이트까지 업데이트 카운터 컨트롤러는 업데이트의 부재를 감지하고 두 번째 대기열에서 선두 전문가의 식별자를 버립니다. 다음 전문가는 리더의 임무를 맡을 것입니다. Expert Advisor가 데이터베이스 연결 모드로 전환할 때 동일한 컨트롤러가 사용됩니다. 저것들. 두 번째로 가져옵니다. 저것들. 계수 값이 중요하지 않은 M1에서 작업하는 Expert Advisors만 어려움을 겪을 것입니다.
이 솔루션은 작업을 완벽하게 수행했지만 전문가들이 서로 연결되어 있고 데이터베이스를 보충하는 전문가의 이례적인 작업으로 인해 신뢰성이 추가되지 않아 그다지 마음에 들지 않았습니다. 그땐 잘 몰랐고 방법도 몰랐습니다. 1년만에 바꿨습니다.
솔루션 2:
1. 데이터베이스는 타이머에 따라 자체적으로 보충되는 별도의 스레드에서 서비스됩니다.
2. 보충 시 데이터베이스에 대한 액세스는 동기화 개체에 의해 보호됩니다.
모든 것이 훨씬 쉬워졌습니다. 대기열이 없습니다. 하지만 그것도 싫었다. 보충하기 전에 데이터베이스는 따옴표 교환 스크립트를 호출했는데, 이로 인해 때때로 메모리 오버플로가 발생했습니다. 무엇이 MT4를 많이 느려지게 했습니까? 그런 다음 MT4는 2GB의 메모리로 작동했습니다. 이제 그는 4GB로 작업합니다.
솔루션 3:
1. 데이터베이스는 별도의 응용 프로그램입니다. 저것들. MT4와 독립적인 전용 메모리 가 있는 또 다른 프로세스.
2. 데이터베이스가 자동으로 보충됩니다.
3. 데이터 교환은 매핑을 통해 발생합니다. 이는 데이터 교환 속도와 데이터베이스 보충 속도를 증가시켰습니다. 이전에는 디스크에서 모든 것을 읽었습니다. 그렇지 않으면 불가능했습니다. MT4는 작업 메모리가 매우 제한적입니다.
4. 히스토리는 데이터베이스 애플리케이션에서 원격으로 MT4를 통해 업로드됩니다. MT4의 모든 실패 - 언로드한 다음 로드합니다.
5. 4단계는 현재 MT4 디렉토리에 대한 심볼릭 링크를 생성하여 수행됩니다. 저것들. 이것은 현재 MT4의 완전한 사본입니다. 내역은 작업 중인 MT4의 언로드를 기다리지 않고 MT4 디렉토리로 직접 이동 중에 업데이트됩니다.
6. 뮤텍스를 통한 업데이트 시 데이터베이스에 대한 액세스 동기화 크리티컬 섹션은 하나의 프로세스에서만 작동합니다.
===========================
따라서 Dmitry는 자신의 문제를 알지 못하고 대기열에 추가하지 않고 전문가 흐름의 독립성을 유지하지 않고도 문제를 해결할 수 있다고 가정할 가능성이 큽니다. 그러면 전체 작업의 신뢰성과 성능이 향상됩니다. 이것은 내가 여러 페이지에서 (스레드의 독립성) 이야기한 것입니다.
이것은 원자적 액세스 블록이며 동기화되지 않습니다. 예금만을 언급하는 것은 의미가 없습니다. 예금 매개변수의 기능을 호출하는 것은 트릭 없이 그 자체로 원자적입니다. 원자적으로 완료되면 고문의 모든 작업입니다. 이것이 당신이 문제를 해결하는 방법입니다. 당신은 당신이 뭔가를 했다고 생각하지만 실제로는 환상입니다.
드미트리, 주변에 바보들만 있다고 생각하지 마세요. Sergey의 질문에서 그가 문제에 대해 잘 알고 있음이 분명합니다.
물론 단순히 동기화와 함께 예금의 매개 변수를 참조하는 것은 의미가 없습니다. 이러한 매개변수를 변경하려면 동기화가 필요합니다. 병렬 Expert Advisor는 이미 변경된 올바른 매개변수를 수신하고 변경하는 과정에서 수신하지 않도록 합니다.
모두에게 좋은!
말해줘, 누군가는 이것이 어떤 종류의 문제인지 알고 있을지도 모른다. ex4 파일을 컴파일한 후에도 Metalang을 통해서도 나타나지 않는다. 이것들로 무엇을 할 수 있습니까? 며칠 전에는 모든 것이 잘 작동했습니다.
컴파일은 오류 없이 실행되며 의도적으로 오류를 도입하더라도 실행됩니다.
Windows7이 있는 경우 가상 폴더에서 검색해 보세요.
c:\Users\Your 폴더\AppData\Local\VirtualStore\Program Files (x86)\MT4 폴더\experts\
귀하의 폴더 및 폴더 MT4 대신 실제 디렉토리를 대체하십시오.
옛날 옛적에 여기 친절한 사람들이 "마지막 마감 위치 티켓 반환" 기능에서 "마지막 두 마감 위치 티켓 반환" 기능을 만드는 방법을 제안했습니다.
그리고 "3개의 폐쇄 위치 티켓" 기능이 필요할 때 (유사성 및 선택 방법을 사용하여) 구현할 수 없었습니다.
도와주세요,
이것은 두 개의 사본이고 두 번째 사본은 약간의 변경 사항이 있음을 알 수 있습니다. 계속할 수 있었지만...
나는 세 번째 티켓에 대해이 옵션을 가지고 있습니다 .. 그리고 어떤 이유로 그것은 첫 번째 위치의 티켓을 다시 반환합니다 ...
바꾸다
에
하나의 함수에서 세 개의 값을 반환하는 작업만 명확하지 않습니다.
바꾸다
에
하나의 함수에서 세 개의 값을 반환하는 작업만 명확하지 않습니다.
요점은 마지막 N 위치의 결과를 계산하는 것입니다. 이를 위해 나는 그들의 티켓이라고 부릅니다. 그리고 거기에는 기술의 문제가 있습니다.
바꾸다
에
효과가 있었다! 솔직히 말해서, AND 대신 OR을 대체하는 아이디어가 있었습니다. 하지만 ... :))))))))))))))))))))))))
감사하다! 이제 논리가 명확해졌습니다. 닫힌 15개를 세려면 코드를 풍선 크기로 부풀려야 합니다!
이 모든 것을 하나의 사이클에 압축할 수 있습니까? 필요한 트랜잭션 수 N의 매개변수만 대체하십시오.
1. 헛된 당신입니다. 그의 알고리즘에 대한 나의 감탄은 거기에도 표현되어 있습니다. 이것은 동일한 HRENFIX입니다. 그런 그에게 또 다른 별명이 생겼다.
스크립트 이름의 접두사에서 우리 닉네임의 첫 글자.
================
2. Dmitry, 모든 것에도 불구하고 공개 대상이 아닌 일부 비밀 알고리즘으로 비밀 문제를 해결해 주셔서 진심으로 기쁩니다.
3. 모든 것이 매우 신비롭게 보였습니다. 자랑해주셔서 감사합니다. 당신은 의심할 여지 없이 이 포럼에서 가장 멋진 프로그래머이며 아마도 전 세계에서 가장 멋진 프로그래머일 것입니다!
1. 아 네! 이것이 귀하의 코드 또는 귀하의 친구인 것으로 판명된 후. Abaldet는 가장 무가치하고 수치스러웠지만 이제 그는 즉시 유쾌해졌습니다.
2. 내가 어떤 프로그래머인지, 무엇을 알고 무엇을 할 수 있는지, 어떻게 알며 할 수 있는지, 무엇을 모르고 무엇을 할 수 없는지 - 어떻게든 스스로 알아내겠습니다.
3. 작업은 전혀 비밀이 아니며 절대적으로 명백하며 여기에서 공개적으로 정의되었습니다. 이해할 수 있는 사람은 문제 없이 즉시 이해했습니다. 나는 비밀스러운 마법의 방법이 아니라 일반적인 표준과 명시적인(세계적으로 유명한) 방법으로 해결했습니다. 여기 자랑하는 게 아니라 너 때문에 기적이라 웃는다. 당신의 과대망상증만이 당신이 이것을 이해하고 깨닫도록 허용하지 않습니다.
1. 아 네! 이것이 귀하의 코드 또는 귀하의 친구인 것으로 판명된 후. Abaldet는 가장 무가치하고 수치스러웠지만 이제 그는 즉시 유쾌해졌습니다.
2. 내가 어떤 프로그래머인지, 무엇을 알고 무엇을 할 수 있는지, 어떻게 알며 할 수 있는지, 무엇을 모르고 무엇을 할 수 없는지 - 어떻게든 스스로 알아내겠습니다.
3. 작업은 전혀 비밀이 아니며 절대적으로 명백하며 여기에서 공개적으로 정의되었습니다. 이해할 수 있는 사람은 문제 없이 즉시 이해했습니다. 나는 비밀스러운 마법의 방법이 아니라 일반적인 표준과 명시적인(세계적으로 유명한) 방법으로 해결했습니다. 여기 자랑하는 게 아니라 너 때문에 기적이라 웃는다. 당신의 과대망상증만이 당신이 이것을 이해하고 깨닫도록 허용하지 않습니다.
얘들아, 다른 데 가서 문질러! 여기 사람들은 실용적인 문제를 해결합니다. 그리고 당신은 감정으로 가지를 막습니다 ...
얘들아, 다른 데 가서 문질러! 여기 사람들은 실용적인 문제를 해결합니다. 그리고 당신은 감정으로 가지를 막습니다 ...
당신은 그것에 대해 나에게 무엇을 쓰고 있습니까? 그것을 받아 Zhunko가 씁니다. 그가 대화 내용을 이해할 수 없는 것은 넷째 날입니다. 다른 사람들은 첫날에 이해했습니다.
물론 모든 분쟁은 제한되어야 합니다. 그렇지 않으면 이미 이성의 한계를 넘어설 수 있습니다.
두 입장이 모두 명시된 후 당사자는 동의할 수도 있고 의견을 유지할 수도 있습니다. - 그것은 그들의 권리입니다. 사람이 틀려도. 모든 사람은 실수할 권리가 있습니다.
이것이 이와 같은 공개 토론인 경우 관찰자는 각 측면의 주장을 보고 문제에 대해 도달한(또는 도달하지 않은) 합의에 관계없이 모든 사람이 자신의 솔루션 버전(또는 둘 다)을 선택할 기회가 있습니다.
그러나 개인(과제, 질문, 사례가 아님)에 대한 비난과 호소로 전환하는 것은 이미 권위를 축소시키는 것입니다. 이것은 불필요하고 정죄된 것입니다(개인적인 모욕의 경우).
문제를 해결하기 위한 논거와 방법이 오래전부터 제시되어 왔기 때문에 양측이 이 문제에서 멈추고 서로에게 호소할 것을 제안합니다.
분명히 프로그램 문제를 해결할 때 토론자가 전문가라면 분쟁을 수행하는 문제에서는 초보자입니다. 지점의 주제를 벗어나지 않지만 전문적인 조언을 제공할 수 있습니다. 이 조언이 들리기를 바랍니다.
1. 아 네! 이것이 귀하의 코드 또는 귀하의 친구인 것으로 판명된 후. Abaldet는 가장 무가치하고 수치스러웠지만 이제 그는 즉시 유쾌해졌습니다.
2. 내가 어떤 프로그래머인지, 무엇을 알고 무엇을 할 수 있는지, 어떻게 알며 할 수 있는지, 무엇을 모르고 무엇을 할 수 없는지 - 어떻게든 스스로 알아내겠습니다.
3. 작업은 전혀 비밀이 아니며 절대적으로 명시적이며 여기에서 공개적으로 정의되었습니다. 이해할 수 있는 사람은 문제 없이 즉시 이해했습니다. 나는 비밀스러운 마법의 방법이 아니라 일반적인 표준과 명시적인(세계적으로 유명한) 방법으로 해결했습니다. 여기 자랑하는 게 아니라 너 때문에 기적이라 웃는다. 당신의 과대망상증만이 당신이 이것을 이해하고 깨닫는 것을 허용하지 않습니다.
1. 코드와 알고리즘의 차이가 느껴지시나요? 또한 알고리즘은 차트 창을 여는 것과 관련이 없습니다. 코드가 수정되었습니다. 차트가 열리는 곳은 크게 바뀌지 않았습니다. 그 당시에는 다른 선택지가 없었습니다. DLL에서 만든 여자친구에게. 더 듬직 해요.
2. 훌륭하다! 당신은 최고입니다!
3. 당신은 이것을 의미합니다:
1) 작업: 각 스크립트(EA)는 다른 모든 스크립트의 존재를 알아야 합니다.
2) 문제: 실패가 발생하면 실패한 전역의 전역이 불안정하게 멈추고 대기열이 중지됩니다.
3) 솔루션:
각 exp는 공통 접두사 + 창 핸들 + 기호라는 이름으로 1개의 전역을 구성합니다. 전역 값은 이 기호의 마지막 눈금 시간입니다. 자체 핸들이 있는 2개의 공통 글로벌(작동한 후 핸들을 기록하거나 가장 오래된 핸들인 경우 재설정)
대기열을 오름차순(핸들)으로 구성하고 가장 오래된 대기열은 두 번째 전역을 재설정합니다.
각 exp에서 우리는 세 개의 배열(구조가 없는 경우)을 만듭니다. symbol\handle\last access time\last tick time.
모든 전문가는 모두에 대해 (마지막 액세스 시간 \ 마지막 틱 시간)을 추적하고 차이가 발생하면(exp 중 하나에서 실패) 실패한 전문가의 두 전역이 삭제되고 비활성화된 것으로 간주됩니다. 배열의 셀이 제거됩니다(배열이 다시 작성됨).
대기열이 복원됩니다.
실제로 이것은 가장 활동적인 차트(자주 틱)에 있는 exp에 의해 수행됩니다.
정상적인 정의에서 각 경험치는 자체적으로 정리됩니다.
최대 건너뛰기는 1틱입니다.
추신. 그러나 일반적으로 하나의 다중 통화를 만드는 것이 좋습니다.
2008년에도 비슷한 문제가 있었습니다. 나는 어떤 사람들처럼 비밀을하지 않을 것입니다. 어떤 일을 하고, 어떻게 결정했는지, 왜 이런 식으로 문제를 해결하는 것이 성공하지 못했다고 생각하는지 구체적인 예를 들어 말씀드리겠습니다.
===============================
작업의 초기 데이터:
1. 여러 개의 동일한 루프형 Expert Advisors가 있습니다. 저것들. 완전히 독립적인 스레드.
2. 일부 전문가가 액세스할 수 있는 8개 그룹으로 나누어진 계수 데이터베이스가 있습니다. 2GB의 데이터베이스 크기.
3. 데이터베이스는 때때로 보충됩니다. 2시간의 배수 기간 후에 보충됩니다. 처리 시간은 하루 중 시간의 다양성에 따라 다릅니다. 시간 및 프로세서 성능의 다양성에 따라 5분에서 45분 사이의 시간이 소요됩니다.
일:
1. 때문에 데이터베이스 보충에는 많은 시간이 걸리므로 보충을 담당하는 전문가는 한 명만 있으면 됩니다. 그렇지 않으면 끝날 때까지 기다릴 수 없습니다.
2. 업데이트하는 동안 데이터베이스에 대한 액세스를 비활성화해야 합니다. 전문가가 작업하는 계수 업데이트가 크게 느려지지 않도록 그룹별로 수행하십시오.
3. 현재 업데이트 중인 계수로 작업하는 Expert Advisors는 이전 계수로 작업해야 합니다.
4. 특정 그룹의 계수 업데이트 기간 동안 이 그룹으로 전환된 전문가는 단일 계수로 작업하여 이를 보고해야 합니다. 완료되면 업데이트가 새 요소로 전환되어야 합니다. 3번 항목도 마찬가지입니다.
현재 솔루션:
1. 인덱스로 구성된 전문가 식별자의 공통 대기열이 생성되었습니다.
2. 인덱스로 구성된 데이터베이스에 액세스하는 전문가의 식별자 대기열이 생성되었습니다.
3. 두 대기열 모두 공유 리소스입니다. 대기열에 대한 액세스는 단일 동기화 개체에 의해 동기화됩니다.
4. 2단계의 첫 번째 전문가를 데이터베이스 업데이트 담당 전문가로 임명합니다.
5. 또한 Rustam이 설명한 것과 거의 같습니다. DLL에서 구현하기 때문에 조금 더 쉽습니다.
식별자는 종단 간 인덱스입니다. 전문가가 제거되면 식별자가 대기열에서 제거됩니다. 재인덱싱이 수행되지 않습니다. 나머지 전문가들은 지수를 남깁니다.
새로운 전문가를 추가할 때 마지막 전문가의 인덱스가 해당 번호와 일치하지 않으면 첫 번째 무료 이전 인덱스가 할당됩니다. 그렇지 않으면 새 인덱스가 할당됩니다.
설명자 및 차트 도구에 바인딩할 필요가 없습니다. 또한 업로드 실패를 추적할 필요가 없습니다. 충돌은 없었습니다. 설령 이런 일이 일어나더라도 재앙은 아닐 것이다. Expert Advisors는 이전 계수로 계속 작업할 것입니다. 다음 업데이트까지 업데이트 카운터 컨트롤러는 업데이트의 부재를 감지하고 두 번째 대기열에서 선두 전문가의 식별자를 버립니다. 다음 전문가는 리더의 임무를 맡을 것입니다. Expert Advisor가 데이터베이스 연결 모드로 전환할 때 동일한 컨트롤러가 사용됩니다. 저것들. 두 번째로 가져옵니다. 저것들. 계수 값이 중요하지 않은 M1에서 작업하는 Expert Advisors만 어려움을 겪을 것입니다.
이 솔루션은 작업을 완벽하게 수행했지만 전문가들이 서로 연결되어 있고 데이터베이스를 보충하는 전문가의 이례적인 작업으로 인해 신뢰성이 추가되지 않아 그다지 마음에 들지 않았습니다. 그땐 잘 몰랐고 방법도 몰랐습니다. 1년만에 바꿨습니다.
솔루션 2:
1. 데이터베이스는 타이머에 따라 자체적으로 보충되는 별도의 스레드에서 서비스됩니다.
2. 보충 시 데이터베이스에 대한 액세스는 동기화 개체에 의해 보호됩니다.
모든 것이 훨씬 쉬워졌습니다. 대기열이 없습니다. 하지만 그것도 싫었다. 보충하기 전에 데이터베이스는 따옴표 교환 스크립트를 호출했는데, 이로 인해 때때로 메모리 오버플로가 발생했습니다. 무엇이 MT4를 많이 느려지게 했습니까? 그런 다음 MT4는 2GB의 메모리로 작동했습니다. 이제 그는 4GB로 작업합니다.
솔루션 3:
1. 데이터베이스는 별도의 응용 프로그램입니다. 저것들. MT4와 독립적인 전용 메모리 가 있는 또 다른 프로세스.
2. 데이터베이스가 자동으로 보충됩니다.
3. 데이터 교환은 매핑을 통해 발생합니다. 이는 데이터 교환 속도와 데이터베이스 보충 속도를 증가시켰습니다. 이전에는 디스크에서 모든 것을 읽었습니다. 그렇지 않으면 불가능했습니다. MT4는 작업 메모리가 매우 제한적입니다.
4. 히스토리는 데이터베이스 애플리케이션에서 원격으로 MT4를 통해 업로드됩니다. MT4의 모든 실패 - 언로드한 다음 로드합니다.
5. 4단계는 현재 MT4 디렉토리에 대한 심볼릭 링크를 생성하여 수행됩니다. 저것들. 이것은 현재 MT4의 완전한 사본입니다. 내역은 작업 중인 MT4의 언로드를 기다리지 않고 MT4 디렉토리로 직접 이동 중에 업데이트됩니다.
6. 뮤텍스를 통한 업데이트 시 데이터베이스에 대한 액세스 동기화 크리티컬 섹션은 하나의 프로세스에서만 작동합니다.
===========================
따라서 Dmitry는 자신의 문제를 알지 못하고 대기열에 추가하지 않고 전문가 흐름의 독립성을 유지하지 않고도 문제를 해결할 수 있다고 가정할 가능성이 큽니다. 그러면 전체 작업의 신뢰성과 성능이 향상됩니다. 이것은 내가 여러 페이지에서 (스레드의 독립성) 이야기한 것입니다.
죄송합니다. 대답하지 않았습니다:
이것은 원자적 액세스 블록이며 동기화되지 않습니다. 예금만을 언급하는 것은 의미가 없습니다. 예금 매개변수의 기능을 호출하는 것은 트릭 없이 그 자체로 원자적입니다. 원자적으로 완료되면 고문의 모든 작업입니다. 이것이 당신이 문제를 해결하는 방법입니다. 당신은 당신이 뭔가를 했다고 생각하지만 실제로는 환상입니다.
물론 단순히 동기화와 함께 예금의 매개 변수를 참조하는 것은 의미가 없습니다. 이러한 매개변수를 변경하려면 동기화가 필요합니다. 병렬 Expert Advisor는 이미 변경된 올바른 매개변수를 수신하고 변경하는 과정에서 수신하지 않도록 합니다.