Yury_Malich
Столкнулся сегодня с одной интересной проблемой под Вистой: если открыть файл с опцией FILE_FLAG_RANDOM_ACCESS и начать его читать, то система по мере чтения начинает активно начинает выделять память вплоть до размера файла.
Может никто не проверял? В 99% случаев файлы открывают со стандартными флагами.

Some time ago I wrote for Windows XP, a process that reads a large file from beginning to end once, then, based on the user input it accesses a small part of the file randomly, because of this, I used the FILE_FLAG_RANDOM_ACCESS to call CreateFile. The process has been working fine for about 3 years on XP and Server 2003, performance may not be optimal but at least descent. Recently I ran this process on Vista, and the first thing I noticed was that the overall performance of the whole system became unacceptably slow just few seconds after the process started. It took me a full day to figure out what the problem was, but finally I realized that reading the file from beginning to end with the FILE_FLAG_RANDOM_ACCESS on causes the file buffer to grow bigger than the physical memory, with all the obvious consequences. I changed the flags parameter of CreateFile to FILE_FLAG_SEQUENTIAL_SCAN instead, and it solved the problem. I ran the process a few of times and I got a consistent 25 seconds time response. HOWEVER!… after that, I decided to test what would happened if I changed the flags parameter to 0, so I did, I was surprised when I saw it took about 2 minutes to finish, I ran it again to be sure, but with the same results. I thought; well is clear I should use FILE_FLAG_SEQUENTIAL_SCAN, so I changed back the flags parameter, and ran again the test, even more surprised I was when it took more than 2 minutes to finish this time, I ran the process again and I got the similar results, the third time I ran the test I realized the hard disk kept working long after my process had finished, so that means other process was interfering with my tests. Next day I ran again the process several times and it took between 27 and 68 seconds to complete, but never getting the same result twice. The process is file driven, so as long as the file doesn’t change (and it didn’t) the process performs exactly the same steps every time it runs, but even so, I am not getting the consistent results I do expect. I’m sure if my process ran alone then I could be able to get a consistent result and thus be able to make the right decision not only in this issue, but in many others. I now realize, perhaps I based my choices on undependable tests… so my question is: How can I define a RELIABLE “performance test” environment, so the same test under the same conditions gives always the same result?

Stranger_NN
Вполне возможно. Я где-то видел рекомендацию использовать этот флаг для баз данных

Merlin
Ага, я знаю. И пост этот уже видел.
Проблема в том, что FILE_FLAG_RANDOM_ACCESS реально (раза в 3-4 на моей задаче) повышает скорость чтения на XP если нужно параллельно читать два или более файлов.

Yury_Malich
А файл открывается асихронно?

Yury_Malich, дык то-то и оно, это действительно ОЧЕНЬ полезный флаг для БД... И, полагаю, широко распространенный...

Merlin
Файлы открываются и читаются синхронно.

Хуже всего, что порой можно Винду ввести в ступор, одновременно открыв файл на запись и отложенное чтение.
В результате чего данные грохаются

yanckoff
Хуже всего, что порой можно Винду ввести в ступор, одновременно открыв файл на запись и отложенное чтение.
Тут я ступоре. Как можно открыть файл на отложенное чтение? Что такое отложенное чтение?

Merlin
From MSDN:
The character string mode specifies the type of access requested for the file, as follows:

"r" — Opens for reading. If the file does not exist or cannot be found, the fopen_s call fails.
"w" — Opens an empty file for writing. If the given file exists, its contents are destroyed.
"a" — Opens for writing at the end of the file (appending) without removing the EOF marker before writing new data to the file; creates the file first if it doesn't exist.
"r+" — Opens for both reading and writing. (The file must exist.)
"w+" — Opens an empty file for both reading and writing. If the given file exists, its contents are destroyed.
"a+" — Opens for reading and appending; the appending operation includes the removal of the EOF marker before new data is written to the file and the EOF marker is restored after writing is complete; creates the file first if it doesn't exist.

yanckoff
From MSDN:
The character string mode specifies the type of access requested for the file, as follows
Где Вы нашли хоть что-то про отложенное чтение?
Я, пожалуй, догадываюсь откуда ноги растут. Наверное, Вы где-то слышали звон про упреждающее чтение и отложенную запись. Угадал? Есть такое дело, есть. Но к тому, что Вы написали, это не имеет прямого отношения. Звон из другой оперы.

Что такое отложенное чтение? Это типа откладываем хендл файла напотом?

Merlin
Разберем случай, когда в одном трэде мы открываем файл на чтение и запись "r+", а в другом трэде его же на чтение"r"
Что же получится?
Один трэд не успел закинчить запись а второй начал чтение, в итогу у второго процесса старые данные, а в первый записал в файл новые.
Приходится извращаться расстановкой мьютексов. Что формирует "отложенное" чтение до окончания записи в файл.

>Один трэд не успел закинчить запись а второй начал чтение, в итогу у второго процесса старые данные, а в первый записал в файл новые.

1. thread и process -- это не одно и то же;
2. mutual exclusives являются высокоуровневым решением, причём не самым эффективным;
3. есть сквозная запись с барьером по чтению (используется обычно с железом для in-order I/O);
4. большинство проблем великолепно решается на железном уровне
(см. механизмы когерентности кэшей write invalidate и write update).

yanckoff
Разберем случай, когда в одном трэде мы открываем файл на чтение и запись "r+", а в другом трэде его же на чтение"r"
Может лучше не будем? Мне то давно все ясно, но тогда и другие тоже поймут.
Безусловно, открывая файл из разных потоков, необходимо использовать те или иные средства синхронизации. Поскольку тред, надо понимать это thread, то бишь поток, то для того, чтобы использовать мьютексы для синхронизации в этом случае, надо иметь очень веские причины (даже не знаю уж какие). Мьютекс — штука "дорогая" с точки зрения затрат ресурсов процессора и используется для синхронизации между процессами, а не между потоками. Для синхронизации внутри одного процесса есть средства значительно более "дешевые" и не менее эффективные. Например, критические секции. Ситуация, описываемая Вами, совершенно тривиальная, встречается сплошь и рядом... Некий модифицируемый ресурс защищается на время модификации от любого доступа со стороны. Причем это касается не только файлов. Любой разделяемый ресурс в многопоточной программе должен защищаться подобным образом. Не вижу в этом ничего связанного с предметом нашей беседы, а именно с неким процессом "открытия файла на запись и отложенное чтение". Файл не может открываться на отложенное чтение. Нет такого. Понимаете?

Walter S. Farrell

Цитата:

---

большинство проблем великолепно решается на железном уровне.
thread и process -- это не одно и то же;

---

Вопрос именно в использовании чтения/записи в одном процессе, но разными трэдами процесса.
В свое время я первый раз столкнулся с этой проблемой. Был твердо уверен, что ОС сама в состоянии разрешить конфликты в трэдах. Оказалось что не так.
Согласен, что мьютекс — не самое эффективное средство, но это было первое, что пришло мне в голову.

Merlin

Цитата:

---

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

---

Я вижу, что я не удачно выразился, про "отложенное чтение", ситуацию я описал выше.
Наивно предпологал, что функцию "защиты" возьмет на себя ОС. Как выяснилось фигушки, все пришлось делать ручками

yanckoff
Наивно предпологал, что функцию "защиты" возьмет на себя ОС. Как выяснилось фигушки, все пришлось делать ручками
Воистину США — страна громадных возможностей.

Merlin

Цитата:

---

Воистину США — страна громадных возможностей

---

Кстати случай был не в США, а еще в России...
Воистину, надейся на себя , но стоит все же почитывать иногда инструкции

yanckoff
Кстати случай был не в США, а еще в России...
А при чём тут Виста?
Хуже всего, что порой можно Винду ввести в ступор, одновременно открыв файл на запись и отложенное чтение.
В результате чего данные грохаются
Вы, пардон, делаете полную фигню, а Винда виновата в том, что при этом данные "грохаются"?
Воистину, надейся на себя , но стоит все же почитывать иногда инструкции
Точно. Здравый смысл еще никогда знаний не заменял.

Merlin
А где я говорил про Висту? Я говорил про Виндууууууууу

Цитата:

---

Вы, пардон, делаете полную фигню, а Винда виновата в том, что при этом данные "грохаются"?

---

Ну если Винда позволяет одновремено отвкрыть файл и на чтение и на запись, то хотелось бы ожидать, что функцию арбитра ОСь также возьмет на себя

yanckoff
Я говорил про Виндууууууууу
А мы с Yury_Malich обсуждали нюанс, появившийся у него в Висте. И вообще топик про Висту.

Ну если Винда позволяет одновремено отвкрыть файл и на чтение и на запись, то хотелось бы ожидать, что функцию арбитра ОСь также возьмет на себя
Зачем и как? Разработчик решает что и как можно делать с файлом. Создайте любой текстовый файл. Откройте его Notepad-ом. Удалите. Получилось? Проделайте тоже самое еще раз, но откройте Word-ом и снова попробуйте удалить. Получилось? Какое поведение файловой системы было правильным?

Merlin

Цитата:

---

А мы с Yury_Malich обсуждали нюанс, появившийся у него в Висте. И вообще топик про Висту.

---

Ну топик периодически наполняется просто любыми измышлениями о Винде. Но признаю то, что мой пост был не в кассу.

Цитата:

---

Зачем и как? Разработчик решает что и как можно делать с файлом.

---

Пример некорректен... Поскольку Notepad открывает на чтение, а Word на запись.
Зачем, давать возможность открывать файл для чтения и для записи одновременно и при этом требовать самостоятельно регламентировать доступк этому файлу?

yanckoff
Пример некорректен... Поскольку Notepad открывает на чтение, а Word на запись.
Применительно к нашему предыдущему разговору — ДА. Мой пример не является аналогией. Но он показывает возможность различного подхода к работе с файлом. И тот, и другой имеют право на жизнь. К слову, Notepad на самом деле ИМХО просто копирует файл себе в память и даже не держит файл открытым.
Зачем, давать возможность открывать файл для чтения и для записи одновременно и при этом требовать самостоятельно регламентировать доступк этому файлу?
А почему нет? Если кто-то открыл файл на запись, то сделать это еще кому-либо не удастся. А на чтение — открывайте скоко влезет, не жалко. Если же нужна проверка корректности содержимого и т.п., то для этого надо использовать механизмы баз данных. Создаете в ней курсор, выбираете пессимистичный тип блокировки и вперед. Запись полностью блокируется на все время работы с ней. Ну или написать свою базу данных.

Merlin

Цитата:

---

Если же нужна проверка корректности содержимого и т.п., то для этого надо использовать механизмы баз данных.

---

Во это меня и смутило. Механизм для работы есть, но для полного счастья нужно "обработать его напильником" ©

yanckoff,

Цитата:

---

Зачем, давать возможность открывать файл для чтения и для записи одновременно и при этом требовать самостоятельно регламентировать доступк этому файлу?

---

Элементарно, вполне реальная и простая ситуация. Один поток что-то непрервыно делает и пишет данные в лог. Другой поток периодически куда-то этот лог отсылает и чистит. Оба потока владеют хендлом файла, открытого один раз в режиме "r+". Как правильно заметил Merlin, тут без вариантов должна использоваться только критическая секция. Можно конечно выпендриться и использовать мутекс, но он тут совсем ни к чему.

В принципе yanckoff-а можно понять. Ситуацию, когда читающий поток ждёт, пока пишущий поток закончит писать и освободит критическую секцию, чисто интуитивно можно назвать "отложенным чтением". Но в общепринятой терминологии такого выражения вроде нет.

Цитата:

---

Ну если Винда позволяет одновремено отвкрыть файл и на чтение и на запись, то хотелось бы ожидать, что функцию арбитра ОСь также возьмет на себя

---

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

Yury_Malich, можно поинтересоваться а зачем вы открываете файл именно с флагом FILE_FLAG_RANDOM_ACCESS. Вам реально нужен Random Access к его содержимому? Под вистой попробуйте функцию

Код:

BOOL FlushFileBuffers(
  HANDLE hFile
);

В вашей ситуации может помочь.

zhe

Цитата:

---

можно поинтересоваться а зачем вы открываете файл именно с флагом FILE_FLAG_RANDOM_ACCESS. Вам реально нужен Random Access к его содержимому?

---

Ответ здесь http://forum.radeon.ru/viewtopic.php?p=442777#p442777

Цитата:

---

Под вистой попробуйте функцию

---

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

B.R@ven

Цитата:

---

но один фиг 700-800 метров съедается только системой

---

А какими процессами и сколько именно? Я пытаюсь ради спортивного интереса воспроизвести на своем ноуте (конфиг в инфо) пока не получилось
Вижу уйму жалоб, уже стало просто интересно

zhe

Цитата:

---

Но в общепринятой терминологии такого выражения вроде нет

---

За свое костноязычие я уже извинился

denis!!!

Цитата:

---

Даешь работу с файлами только стандартными C функциями! (msvcrt.dll)

---

И при этом хорошо документированными

yanckoff

Цитата:

---

Я пытаюсь ради спортивного интереса воспроизвести на своем ноуте (конфиг в инфо) пока не получилось

---

Жаль, что висты нет под рукой, тоже хочется попробовать

Цитата:

---

За свое костноязычие я уже извинился

---

Это был не упрёк, а просто размышления вслух так сказать.

denis!!! писал(а):

---

Даешь работу с файлами только стандартными C функциями! (msvcrt.dll)

---

"Давать"-то я могу, но боюсь вам, как пользователю не очень понравится, если задача по обработке одних и тех же файлов вместо 30 секунд будет идти 2 минуты.

denis!!!

Цитата:

---

msvcrt.dll

---

Кроссплатформенно?

yanckoff

Цитата:

---

Кроссплатформенно?

---

Ну да. И для Висты, и для ХР. Это теперь так называется. А Вы небось про Линукс подумали?

yanckoff
ArtLonger
Ну вы даёте может не так меня поняли. msvcrt.dll является аналогом стандартной C библиотеки. Включив stdlib, stdio или что там ещё в inсlude — при компиляции этого исходника под виндой будет юзаться msvcrt.dll, под линуксов libc или libcstd или что там играет роль стандартной библиотеки. И в маке тоже будет работать. То есть кросс-платформенно. Может я не совсем правильно выразился — надо было в скобках написать stdlib, а не msvcrt.dll

denis!!!
Это всё фигня. Настояшая кроссплатформенность — это когда приложение работает и под ХР, и под Вистой. Остальное изврат, не достойный настоящего мачо.

denis!!!

Цитата:

---

надо было в скобках написать stdlib,

---

Угу.
А то либа от MS VC на Линуксе смотрелась бы гламурно

ArtLonger

Цитата:

---

Настояшая кроссплатформенность — это когда приложение работает и под ХР, и под Вистой

---

ага, а если ещё одновременно и под 32bit и под 64bit, то это ваще шайтан )))

zhe

Русский софт против линуксоидов
"Intel и Microsoft собираются инвестировать в российский рынок ПО. Главным условием для разработчиков станет совместимость их продукции с Windows. Таким образом Microsoft пытается укрепить свои позиции в России на фоне растущего интереса к операционной системе Linux."

Наследник Windows Vista выйдет в первом квартале 2010

Цитата:

---

Изначально ходили слухи, что игра выйдет в 2009 году

---

Windows становится игрой? Супер!

zhe Это вполне закономерно, судя по потреблению ресурсов висты и времени проводимому за её настройкой