즉, 이벤트 루프에서 실행되는 작업 관리자가 여러 작업(핸들러의 수와 동일)을 분산시키면 브레이크가 발생합니까? 결국 핸들러는 많지 않고 몇 개만 있습니다. 작업에 흩어져 이벤트 루프로 릴리스되기만 하면 됩니다. 동시에 핸들러의 실행 플래그를 제어합니다. 핸들러가 작동하고 플래그가 삭제되는 등의 작업이 원으로 이루어집니다. 무언가가 브레이크를 믿지 않습니다. 우리가 처리하는 모든 이벤트가 아니라 동일한 수의 핸들러만 처리합니다. 그리고 핸들러 자체에는 이미 자체 이벤트가 있습니다.
즉, 이벤트 루프에서 실행되는 작업 관리자가 여러 작업(핸들러의 수와 동일)을 분산시키면 브레이크가 발생합니까? 결국 핸들러는 많지 않고 몇 개만 있습니다. 작업에 흩어져 이벤트 루프로 릴리스되기만 하면 됩니다. 동시에 핸들러의 실행 플래그를 제어합니다. 핸들러가 작동하고 플래그가 삭제되는 등의 작업이 원으로 이루어집니다. 무언가가 브레이크로 돌아가지 않을 것입니다. 우리가 처리하는 모든 이벤트가 아니라 동일한 수의 핸들러만 처리합니다. 그리고 핸들러 자체에는 이미 자체 이벤트가 있습니다.
작가가 있는 곳에 독자는 기다려야 한다. 작가가 쓰기 전까지.
한 명 이상의 독자가 있는 경우 그는 자신의 변수에 대해 자신의 의견에 동의해야 합니다. 하나의 화신이 변수의 내용을 변경하는 동안 다른 화신은 기다립니다. 현재 다른 구현이 없더라도 리소스 잠금은 여전히 시스템의 핵심으로 이동하므로 비용이 많이 드는 작업입니다. 모든 화신이 거래 환경을 따를 때 재미가 시작됩니다. 신은 그들이 동시에 거래를 시작하는 것을 금지합니다
일반적으로 젊은이들은 그들이 하는 말을 듣지 않습니다. 여러 번. 예와 함께. 설명과 함께. 연속 10년 이상
아니요. 그것은 당신의 문제입니다. 본질과 결과를 이해하지 못하고이 질문을 제기 한 것은 당신이었습니다.
10년이 넘는 기간 동안 여기에서 여러 번 논의되었습니다.
상대방에게서 나는 건설적인 토론이 아니라 부적절한 공격만 보았다. 적시에 설명과 함께 의사 소통에 개입했다면 불필요한 질문은 없었을 것입니다. 그리고 개발자가 침묵할 때, 당신은 무슨 생각을 해야 할지 모릅니다. 10년 동안 기술의 세계는 많이 변했습니다. 알겠습니다. 이제 제 말을 들으셨다는 것을 이해합니다. 이 질문에 대해 다시 생각하시기 바랍니다. 아마도 잘 될 것입니다. 정말 멋질 것입니다.
상대방에게서 나는 건설적인 토론이 아니라 부적절한 공격만 보았다. 적시에 설명과 함께 의사 소통에 개입했다면 불필요한 질문은 없었을 것입니다. 그리고 개발자가 침묵할 때, 당신은 무슨 생각을 해야 할지 모릅니다. 10년 동안 기술의 세계는 많이 변했습니다. 알겠습니다. 이제 제 말을 들으셨다는 것을 이해합니다. 이 질문에 대해 다시 생각하시기 바랍니다. 아마도 잘 될 것입니다. 정말 멋질 것입니다.
한 명 이상의 독자가 있는 경우 그는 자신의 변수에 대해 자신의 의견에 동의해야 합니다. 한 화신이 변수의 내용을 변경하는 동안 다른 화신은 기다립니다. 현재 다른 구현이 없더라도 리소스 잠금은 여전히 시스템의 핵심으로 이동하므로 비용이 많이 드는 작업입니다. 모든 화신이 거래 환경을 따를 때 재미가 시작됩니다. 신은 그들이 동시에 거래를 시작하는 것을 금지합니다
일반적으로 젊은이들은 그들이 하는 말을 듣지 않습니다. 여러 번. 예와 함께. 설명과 함께. 연속 10년 이상
위에서 이해했듯이 문제는 작성자/리더 동기화 자체에 있으며 비용이 많이 들 수 있습니다. 동기화되지 않습니다. 문제 없습니다. 흠, 최적화 측면에서 간결하게 현명합니다. 설명 감사합니다, Slav 삼촌)) 저에게도 화내지 마시기 바랍니다. 나는 마술사가 아니라 배우는 중입니다 )) 실시간 시스템에서는 모든 것이 멀티태스킹 모드에서 작동하고 동기화 절차가 주요 도구이기 때문에 이해할 수 없습니다. 그것은 밝혀졌고 OSRT 브레이크 시스템은? 어찌보면 논리적이지 않습니다. 데드라인, 레이턴시, 지터가 있긴 하지만.
그리고 개체 모델에 대해 무엇을 말할 수 있습니까? 그러면 경쟁이 발생합니다. 또는 그러한 접근 방식에 무엇이 문제가 될 수 있습니까?
Данная библиотека Вам пригодится, когда Вам необходимы несколько таймеров с независимой обработкой и неконфликтующие между собой. Для работы с данной библиотекой важно запомнить следующие правила: В теле вашей программы не должно быть функции OnTimer , т.к. эта функция уже присутствует в файле Timer.mhq Не надо создавать никаких экземпляров...
안녕하세요 니콜라이입니다. 그래서 그렇습니다. 하지만 동기화와 같은 문제가 되지 않을까요? Glory가 말하는 것, 즉 정당하지 않은 브레이크입니다. 아니면 문제가 없을까요? )) 우선 순위와 동기화하는 것보다 비동기식 모델을 사용하지 않는 것이 더 쉬울 수 있습니까? ))
안녕하세요 니콜라이입니다. 그래서 그렇습니다. 하지만 동기화와 같은 문제가 되지 않을까요? Glory가 말하는 것, 즉 정당하지 않은 브레이크입니다. 아니면 문제가 없을까요? )) 우선 순위와 동기화하는 것보다 비동기식 모델을 사용하지 않는 것이 더 쉬울 수 있습니까? ))
저는 감정가가 아닙니다. 그래프에서. 중요성은 현재 작업 완료에 대한 다른 작업 실행 시작의 의존성에 의해 결정됩니다. 다른 기준은 이차적입니다. 그러나 작업 실행 시간 도 있습니다. 또한 동료들 사이에서 가장 중요합니다. 일반적으로 가장 어렵고 가장 슬픈 것은 설정된 우선순위 알고리즘을 이동 중에도 변경할 수 없다는 점입니다. 참고로 질문이 생기기 전에 개발자의 설명을 듣고 싶습니다. 어렵지만 이것이 환경 발전의 올바른 목표입니다.
이러한 객관적인 이유를 지정할 수 있습니까?
정당하지 않은 브레이크
그들이 여기에 쓰는 것을 이해하지 못한다면 미안합니다. 이것은 내 문제가 아니라 대화 주제를 담배 피우지 않는 사람들입니다.
아니요. 그것은 당신의 문제입니다. 본질과 결과를 이해하지 못하고이 질문을 제기 한 것은 당신이었습니다.
10년이 넘는 기간 동안 여기에서 여러 번 논의되었습니다.
정당하지 않은 브레이크
즉, 이벤트 루프에서 실행되는 작업 관리자가 여러 작업(핸들러의 수와 동일)을 분산시키면 브레이크가 발생합니까?
결국 핸들러는 많지 않고 몇 개만 있습니다. 작업에 흩어져 이벤트 루프로 릴리스되기만 하면 됩니다.
동시에 핸들러의 실행 플래그를 제어합니다. 핸들러가 작동하고 플래그가 삭제되는 등의 작업이 원으로 이루어집니다.
무언가가 브레이크를 믿지 않습니다. 우리가 처리하는 모든 이벤트가 아니라 동일한 수의 핸들러만 처리합니다.
그리고 핸들러 자체에는 이미 자체 이벤트가 있습니다.
즉, 이벤트 루프에서 실행되는 작업 관리자가 여러 작업(핸들러의 수와 동일)을 분산시키면 브레이크가 발생합니까?
결국 핸들러는 많지 않고 몇 개만 있습니다. 작업에 흩어져 이벤트 루프로 릴리스되기만 하면 됩니다.
동시에 핸들러의 실행 플래그를 제어합니다. 핸들러가 작동하고 플래그가 삭제되는 등의 작업이 원으로 이루어집니다.
무언가가 브레이크로 돌아가지 않을 것입니다. 우리가 처리하는 모든 이벤트가 아니라 동일한 수의 핸들러만 처리합니다.
그리고 핸들러 자체에는 이미 자체 이벤트가 있습니다.
작가가 있는 곳에 독자는 기다려야 한다. 작가가 쓰기 전까지.
한 명 이상의 독자가 있는 경우 그는 자신의 변수에 대해 자신의 의견에 동의해야 합니다. 하나의 화신이 변수의 내용을 변경하는 동안 다른 화신은 기다립니다. 현재 다른 구현이 없더라도 리소스 잠금은 여전히 시스템의 핵심으로 이동하므로 비용이 많이 드는 작업입니다. 모든 화신이 거래 환경을 따를 때 재미가 시작됩니다. 신은 그들이 동시에 거래를 시작하는 것을 금지합니다
일반적으로 젊은이들은 그들이 하는 말을 듣지 않습니다. 여러 번. 예와 함께. 설명과 함께. 연속 10년 이상
아니요. 그것은 당신의 문제입니다. 본질과 결과를 이해하지 못하고이 질문을 제기 한 것은 당신이었습니다.
10년이 넘는 기간 동안 여기에서 여러 번 논의되었습니다.
상대방에게서 나는 건설적인 토론이 아니라 부적절한 공격만 보았다.
적시에 설명과 함께 의사 소통에 개입했다면 불필요한 질문은 없었을 것입니다.
그리고 개발자가 침묵할 때, 당신은 무슨 생각을 해야 할지 모릅니다. 10년 동안 기술의 세계는 많이 변했습니다.
알겠습니다. 이제 제 말을 들으셨다는 것을 이해합니다. 이 질문에 대해 다시 생각하시기 바랍니다. 아마도 잘 될 것입니다. 정말 멋질 것입니다.
상대방에게서 나는 건설적인 토론이 아니라 부적절한 공격만 보았다.
적시에 설명과 함께 의사 소통에 개입했다면 불필요한 질문은 없었을 것입니다.
그리고 개발자가 침묵할 때, 당신은 무슨 생각을 해야 할지 모릅니다. 10년 동안 기술의 세계는 많이 변했습니다.
알겠습니다. 이제 제 말을 들으셨다는 것을 이해합니다. 이 질문에 대해 다시 생각하시기 바랍니다. 아마도 잘 될 것입니다. 정말 멋질 것입니다.
부적절한 공격 - "쇼, 또?"
모든 응답은 정상이었습니다. 공격은 나에게서만 있었다. 기분이 상했다면 용서해 주세요.
그리고 남자들은 꽤 적절하게 대답했습니다.
작가가 있는 곳에 독자는 기다려야 한다. 작가가 쓰기 전까지.
한 명 이상의 독자가 있는 경우 그는 자신의 변수에 대해 자신의 의견에 동의해야 합니다.
한 화신이 변수의 내용을 변경하는 동안 다른 화신은 기다립니다.
현재 다른 구현이 없더라도 리소스 잠금은 여전히 시스템의 핵심으로 이동하므로 비용이 많이 드는 작업입니다.
모든 화신이 거래 환경을 따를 때 재미가 시작됩니다. 신은 그들이 동시에 거래를 시작하는 것을 금지합니다
일반적으로 젊은이들은 그들이 하는 말을 듣지 않습니다. 여러 번. 예와 함께. 설명과 함께. 연속 10년 이상
위에서 이해했듯이 문제는 작성자/리더 동기화 자체에 있으며 비용이 많이 들 수 있습니다.
동기화되지 않습니다. 문제 없습니다. 흠, 최적화 측면에서 간결하게 현명합니다. 설명 감사합니다, Slav 삼촌))
저에게도 화내지 마시기 바랍니다. 나는 마술사가 아니라 배우는 중입니다 ))
실시간 시스템에서는 모든 것이 멀티태스킹 모드에서 작동하고 동기화 절차가 주요 도구이기 때문에 이해할 수 없습니다.
그것은 밝혀졌고 OSRT 브레이크 시스템은? 어찌보면 논리적이지 않습니다. 데드라인, 레이턴시, 지터가 있긴 하지만.
그리고 개체 모델에 대해 무엇을 말할 수 있습니까? 그러면 경쟁이 발생합니다. 또는 그러한 접근 방식에 무엇이 문제가 될 수 있습니까?
https://www.mql5.com/ru/code/31306
또는 그러한 접근 방식에 무엇이 문제가 될 수 있습니까?
https://www.mql5.com/ru/code/31306
그리고 그것은 무엇으로 가득 차있을 수 있습니까?
안녕하세요 니콜라이입니다. 그래서 그렇습니다.
하지만 동기화와 같은 문제가 되지 않을까요? Glory가 말하는 것, 즉 정당하지 않은 브레이크입니다.
아니면 문제가 없을까요? )) 우선 순위와 동기화하는 것보다 비동기식 모델을 사용하지 않는 것이 더 쉬울 수 있습니까? ))
안녕하세요 니콜라이입니다. 그래서 그렇습니다.
하지만 동기화와 같은 문제가 되지 않을까요? Glory가 말하는 것, 즉 정당하지 않은 브레이크입니다.
아니면 문제가 없을까요? )) 우선 순위와 동기화하는 것보다 비동기식 모델을 사용하지 않는 것이 더 쉬울 수 있습니까? ))
저는 감정가가 아닙니다. 그래프에서. 중요성은 현재 작업 완료에 대한 다른 작업 실행 시작의 의존성에 의해 결정됩니다. 다른 기준은 이차적입니다. 그러나 작업 실행 시간 도 있습니다. 또한 동료들 사이에서 가장 중요합니다. 일반적으로 가장 어렵고 가장 슬픈 것은 설정된 우선순위 알고리즘을 이동 중에도 변경할 수 없다는 점입니다. 참고로 질문이 생기기 전에 개발자의 설명을 듣고 싶습니다. 어렵지만 이것이 환경 발전의 올바른 목표입니다.