Обмен информацией между терминалами с помощью файлов и синхронизация. - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я имею ввиду ситуацию, когда файл в процессе записи, часть данных обновилась, а часть нет. И в этот момент файл одновременно пытаются читать.
Ну так файл сначала открывается для записи, в ОЗУ, потом дописывается и только после этого сохраняется в изменённом виде. И даже если в момент дополнения файла новыми записями другой советник откроет этот файл, то откроет его в предыдущем виде, то-есть без последней записи, которая в данный момент вносится.
Для наглядности, правда не знаю как сейчас в 2010 Excell, а в 2003 проверено, открой книгу с общим использованием, внеси какие-либо изменения и не сохраняя её открой второй экземпляр этой-же книги. Внесённых изменений не увидишь. И только когда сохранишь первый вариант, во втором после обновления появляется внесённое изменение.
Ну так файл сначала открывается для записи, в ОЗУ, потом дописывается и только после этого сохраняется в изменённом виде. И даже если в момент дополнения файла новыми записями другой советник откроет этот файл, то откроет его в предыдущем виде, то-есть без последней записи, которая в данный момент вносится.
Для наглядности, правда не знаю как сейчас в 2010 Excell, а в 2003 проверено, открой книгу с общим использованием, внеси какие-либо изменения и не сохраняя её открой второй экземпляр этой-же книги. Внесённых изменений не увидишь. И только когда сохранишь первый вариант, во втором после обновления появляется внесённое изменение.
Про Excel тут вообще пример не стоит рассматривать. В нутри одного процесса они могут синхронизировать доступ к файлу как угодно.
Лучше рассмотреть физический процесс записи в файл. Наверняка от пишется кусками из какого-то пользовательского или внутреннего буфера в цикле. Поэтому может возникнуть ситуация, когда часть файла уже обновилась, а часть еще нет. И в этот момент при чтении файла могут быть накладки.
Разве не понятно - что запись в файл не есть атомарная операция? :)
Я вижу ситуацию так. Пока идет процесс записи в файл - никто в этот момент не должен его читать. Пока кто-нибудь читает файл - никто не должен в него писать. В рамках одног опроцесса это рулилось бы критической секцией.
так создавайте \ открывайте файл без этих флагов : FILE_SHARE_READ|FILE_SHARE_WRITE и будет вам счастье
без этих флагов пока вы туда пишете , никто его не читает.
Может быть я не с того конца начал рассматривать вопрос. В чем физический смысл флага FILE_SHARE_WRITE - может кто растолкует? Ведь если один и тот же файл пишется из двух мест одновременно - в нем может быть что угодно.
надо рассматривать пару : FILE_SHARE_READ|FILE_SHARE_WRITE
предназначена для одновременного чтения многими программами. а как вы контролируете целостность данных при этом - это уже ваша проблема. типичный пример запись в файл .hst
так как в бинарных файлах размер всегда известен, то контроль довольно простой.
например вы пишете свой файл оффлайн графика, а терминал его читает
Если можно - разверните вашу мысль.
при создании\записи в файл по умолчанию у пишушей программы есть монопольный доступ к файлу. пока вы его не закроете пишушим скритом, читателям к нему доступа не будет и будет генериться ошибка открытия.
читатели пусть читают с этим флагом FILE_SHARE_READ|FILE_SHARE_WRITE и будут иметь при этом совместный доступ.
...
Я вижу ситуацию так. Пока идет процесс записи в файл - никто в этот момент не должен его читать. Пока кто-нибудь читает файл - никто не должен в него писать. В рамках одног опроцесса это рулилось бы критической секцией.
Вы не поняли гениальной изобретательности 70-х. Если контрольные суммы не совпали, то произошло то, чего не должно быть по вашей версии. Просто повторите попытку чтения.