Файловые операции
Всем привет, столкнулся с такой проблемой!!!
Необходимо корректно открыть файл для чтения в тот момент пока его не использует никакая другая программа. Суть в чём.
Пишущий советник пишет данные в файл каждую минуту и если по инструменту в течении минуты не было тика от принудительно пишет значения этой минуты в 55 секунд текущей минуты. Тм самым исключаем пропуски минутных баров на разных инструментах. Пишет он естественно либо ноль либо предыдущее значение. НО
Другой советник читает эти в файлы через 65 секунд после появления сигнала на 5 минутке. Тол есть на 5 минут появился сигнал, советник ждёт минуту и 5 секунд и наченает считывание файлов. При таком комплекте всё работает как часы, НО есть ещё один советник который то же читает файлы но уже через 95 секунд, давая возможность сначала первому советнику прочитать, потом уже он. НО вот не задача данный советник перерисовывает последний сигнал. То есть когда первый советник стоит один проблем нет, но стоит закинуть второй как начинается чехорда. В последствии при компилировании второго сигнал принимает устойчивое положение.
Думаю проблема в том что они толкаются друг с другом и ещё и с пишущим на предмет доступа к файлам. Собственно вопрос: Подскажите изящное решение по 100% надёжности доступа к файлам для чтения????
Есть функция РидФиле, кторая жёстко закинута в цикл while. Врать не буду не до любливаю я его потому как он может запросто повесить любую машину но в данном случае использую именно его с 5 секундной задержкой после каждой итерации. Но всё таки как можно гарантированно прочитать 15 файлов и не столкнуть советника лбами????
Видимо, я что-не понял в условии. Почему нельзя открывать с "FILE_SHARE_READ"?
Не самая лучшая идея использовать файлы для передачи данных.
Поясню. Операции записи/чтения не синхронизированы, соответственно вы не застрахованы от ситуации, когда чтение производится одновременно с записью в разных потоках, со всеми вытекающими. Почему не реализован LockFile, сия тайна покрыта мраком. Более того, никаких механизмов синхронизации между потоками в mql нет, за исключением костыля с глобальными переменными терминала (вообще-то про их потокобезопасность в документации тоже тишина).
ИМХО. Если использование dll не подходит по причине маркета, то из безопасного остается только EventChartCastom
Не самая лучшая идея использовать файлы для передачи данных.
Поясню. Операции записи/чтения не синхронизированы, соответственно вы не застрахованы от ситуации, когда чтение производится одновременно с записью в разных потоках, со всеми вытекающими. Почему не реализован LockFile, сия тайна покрыта мраком. Более того, никаких механизмов синхронизации между потоками в mql нет, за исключением костыля с глобальными переменными терминала (вообще-то про их потокобезопасность в документации тоже тишина).
ИМХО. Если использование dll не подходит по причине маркета, то из безопасного остается только EventChartCastom
тут нужно еще смотреть, что пользователь не грамотный может переключать график или период и сбивать внутренние подсчеты
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Всем привет, столкнулся с такой проблемой!!!
Необходимо корректно открыть файл для чтения в тот момент пока его не использует никакая другая программа. Суть в чём.
Пишущий советник пишет данные в файл каждую минуту и если по инструменту в течении минуты не было тика от принудительно пишет значения этой минуты в 55 секунд текущей минуты. Тм самым исключаем пропуски минутных баров на разных инструментах. Пишет он естественно либо ноль либо предыдущее значение. НО
Другой советник читает эти в файлы через 65 секунд после появления сигнала на 5 минутке. Тол есть на 5 минут появился сигнал, советник ждёт минуту и 5 секунд и наченает считывание файлов. При таком комплекте всё работает как часы, НО есть ещё один советник который то же читает файлы но уже через 95 секунд, давая возможность сначала первому советнику прочитать, потом уже он. НО вот не задача данный советник перерисовывает последний сигнал. То есть когда первый советник стоит один проблем нет, но стоит закинуть второй как начинается чехорда. В последствии при компилировании второго сигнал принимает устойчивое положение.
Думаю проблема в том что они толкаются друг с другом и ещё и с пишущим на предмет доступа к файлам. Собственно вопрос: Подскажите изящное решение по 100% надёжности доступа к файлам для чтения????
Есть функция РидФиле, кторая жёстко закинута в цикл while. Врать не буду не до любливаю я его потому как он может запросто повесить любую машину но в данном случае использую именно его с 5 секундной задержкой после каждой итерации. Но всё таки как можно гарантированно прочитать 15 файлов и не столкнуть советника лбами????