Обмен информацией между терминалами с помощью файлов и синхронизация.

Новый комментарий
 
Многие наверное решали такую задачу по обмену информацией между Метатрейдерами в реальном времени. Наиболее простой способ - использовать файлы. Представим ситуацию - когда один терминал пишет в файл, а другие в этот момент читают из файла. Может получиться абракадабра. Очевидно - без синхронизации между процессами тут не обойтись?
 

Никакой абракадабры быть не должно. Обрати внимание на флаги открытия файла

FILE_SHARE_READ совместный доступ по чтению со стороны нескольких программ
FILE_SHARE_WRITE совместный доступ по записи со стороны нескольких программ
FILE_COMMON расположение файла в общей папке всех клиентских терминалов \Terminal\Common\Files
 
Самый быстрый в работе вариант выделять память себе ссылка так же можно ставить бит, что изменяем допустим и.т.д
 
AlexeyVik:

Никакой абракадабры быть не должно. Обрати внимание на флаги открытия файла

FILE_SHARE_READ совместный доступ по чтению со стороны нескольких программ
FILE_SHARE_WRITE совместный доступ по записи со стороны нескольких программ
FILE_COMMON расположение файла в общей папке всех клиентских терминалов \Terminal\Common\Files
Разве FILE_SHARE_READ и FILE_SHARE_WRITE гарантируют синхронизацию? Где об этом написано?
 
RickD:
Разве FILE_SHARE_READ и FILE_SHARE_WRITE гарантируют синхронизацию? Где об этом написано?
Ты имеешь в виду, что запись могут производить два советника одновременно?
 
AlexeyVik:
Ты имеешь в виду, что запись могут производить два советника одновременно?

Пусть только один эксперт пишет в файл. Можем рассмотреть гипотетическую ситуацию, когда файл очень большой. Пусть пару десятков мегабайт. Разве FILE_SHARE_READ и FILE_SHARE_WRITE гарантируют синхронность? Если гарантируют, то процессы, которые открыли файл с опцией FILE_SHARE_READ, должны или читать неизменный слепок файла, или вообще ждать, пока основной процесс пишет файл. Так ли это - я не уверен.

 

Не надо путать возможность открыть файл для чтения тогда, когда другой процесс в него что-то записывает и получение информации о том, что в данный момент, в этот файл что-то пишется.

Когда в файл что-то пишется, то прочесть это можно только по завершении записи и сохранения на диск. Но вот если один процесс открыл файл без флага FILE_SHARE_READ для чтения, то второй процесс этот файл не сможет открыть для чтения.

Применимо к нашим задачам, видимо ты пишешь свой копировщик сделок, можно (я так думаю) считать, что если файл был открыт для записи и в этот-же момент открыт другим советником для чтения, то ничего страшного не произошло, на следующем тике прочтёт и повторит действия советника мастера.


ps; О какой синхронности ты говоришь? Если открывается ОДИН файл, то с чем его надо синхронизировать? С тем каким он будет после записи в него? А если запись будет "завтра".

Вот если два процесса одновременно откроют файл для записи, то я не знаю что будет на выходе. Как будет определён конец файла, куда дописывать, с какой позиции будет новая запись?

 
RickD:

Пусть только один эксперт пишет в файл. Можем рассмотреть гипотетическую ситуацию, когда файл очень большой. Пусть пару десятков мегабайт. Разве FILE_SHARE_READ и FILE_SHARE_WRITE гарантируют синхронность? Если гарантируют, то процессы, которые открыли файл с опцией FILE_SHARE_READ, должны или читать неизменный слепок файла, или вообще ждать, пока основной процесс пишет файл. Так ли это - я не уверен.


Я решал подобную проблему, когда один пишет, а другие могут читать. Решение с разными флагами оказалось очень громоздким.

Самый простой вариант получился следующий: обязать всех читать файл полностью.

Тот, кто создает файл, в конец его записывает контрольную сумму. Если при чтении контрольные суммы совпали (читатель считает контрольную сумму), то файл прочитан корректно.

Да, и писателю разрешал обновлять файл не слишком часто. Для читателей ограничений нет. 

 
AlexeyVik:

Не надо путать возможность открыть файл для чтения тогда, когда другой процесс в него что-то записывает и получение информации о том, что в данный момент, в этот файл что-то пишется.

Когда в файл что-то пишется, то прочесть это можно только по завершении записи и сохранения на диск. Но вот если один процесс открыл файл без флага FILE_SHARE_READ для чтения, то второй процесс этот файл не сможет открыть для чтения.

Применимо к нашим задачам, видимо ты пишешь свой копировщик сделок, можно (я так думаю) считать, что если файл был открыт для записи и в этот-же момент открыт другим советником для чтения, то ничего страшного не произошло, на следующем тике прочтёт и повторит действия советника мастера.


ps; О какой синхронности ты говоришь? Если открывается ОДИН файл, то с чем его надо синхронизировать? С тем каким он будет после записи в него? А если запись будет "завтра".

Вот если два процесса одновременно откроют файл для записи, то я не знаю что будет на выходе. Как будет определён конец файла, куда дописывать, с какой позиции будет новая запись?

Я имею ввиду ситуацию, когда файл в процессе записи, часть данных обновилась, а часть нет. И в этот момент файл одновременно пытаются читать.
 
Mislaid:

Я решал подобную проблему, когда один пишет, а другие могут читать. Решение с разными флагами оказалось очень громоздким.

Самый простой вариант получился следующий: обязать всех читать файл полностью.

Тот, кто создает файл, в конец его записывает контрольную сумму. Если при чтении контрольные суммы совпали (читатель считает контрольную сумму), то файл прочитан корректно.

Да, и писателю разрешал обновлять файл не слишком часто. Для читателей ограничений нет. 

Интересная идея. Но если файл пишется часто при приходе каждого тика и если тиков прихдит много на новостях, то файл может обновляться слишком часто и читающие файл могут опаздыват ьс полученеим информации.
 
Тут скорее всего нужно думать в сторону мьютекса.
12345
Новый комментарий