Cогласовать вызов из разных потоков WriteFile ReadFile FilePointe

← →
msn777 (2007-11-05 15:09) [0]

Как согласовать одновременный вызов из разных потоков WriteFile, ReadFile и общий FilePointer

Подскажите, может, кто сталкивался с такой задачей.
Пишу приложение, которое должно в одном потоке в реальном режиме времени читать данные из внешнего устройства в ОЗУ ПК, в другом потоке записывать данные из ОЗУ ПК в файл, а в третьем потоке отображать на экране выбираемый пользователем участок данных.

Т.е. получается в потоке записи:
SetFilePointer(hSwapFile, 0, NULL, FILE_END);
WriteFile (hFile …)

В потоке прорисовки:
На основании выбранного участка данных определяем Position
SetFilePointer(hFile, Position, NULL, FILE_BEGIN);
ReadFile (hFile …)

Может ли быть, так что во время чтения, например блока данных размеров 100 KB, после прочтения 50 KB управления получит поток записи, т.е. установит FilePointer в конец файла и запишет очередной блок данных, после чего управление вернется потоку чтения, и он дочитает оставшиеся 50 KB с “правильной” позиции или с конца файла, куда будет указывать FilePointer?
Следит ли Windows за тем что бы, например если ReadFile была прервана (если она прерывается) то не дочитанный кусок был дочитан с той позиции, на которой чтение было прервано? Или нужно использовать какой-то флажок взаимнозапрещающий одновременно запить / чтение.

Спасибо.

← →
MetalFan © (2007-11-05 18:57) [1]

> Следит ли Windows

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

← →
Leonid Troyanovsky © (2007-11-06 12:59) [2]

> msn777 (05.11.07 15:09)

> Пишу приложение, которое должно в одном потоке в реальном
> режиме времени читать данные из внешнего устройства в ОЗУ
> ПК, в другом потоке записывать данные из ОЗУ ПК в файл,
> а в третьем потоке отображать на экране выбираемый пользователем
> участок данных.

Начать надо с того, что если в целевой системе не более 1 процессора,
то все эти доп. потоки излишни (особенно в "реальном режиме").

--
Regards, LVT.

← →
tesseract © (2007-11-06 17:15) [3]

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

Самому конечн, рекомендую критические секции на запись в ОЗУ. Гарантировано не будет пересечений.

← →
msn777 (2007-11-07 12:02) [4]

Спасибо за советы.

> Начать надо с того, что если в целевой системе не более 1 процессора,
> то все эти доп. потоки излишни (особенно в "реальном режиме").

Понятно что настоящего Real Time в Windows нет, а потоки необходимы для выполнения 3-х почти параллельных действий.

> Самому конечн, рекомендую критические секции на запись в ОЗУ. Гарантировано не будет пересечений.

Не ясно зачем КС на запись в ОЗУ?

Может разумно использовать 2 дескриптора одно и тоже файла, один для записи, другой для чтения.

← →
Сергей М. © (2007-11-07 12:23) [5]

> зачем КС на запись в ОЗУ?

Как ты вообще собрался что-то там записывать в ОЗУ ?
Прикладной процесс не имеет доступа к физ.памяти, только к виртуальной.

← →
tesseract © (2007-11-07 14:39) [6]

> Не ясно зачем КС на запись в ОЗУ?

Про коллизии слышал - ты точно уверен, что у тебя запись в озу не пересечёться с чтением? И что ты кучку мусора не считаешь?.

← →
Leonid Troyanovsky © (2007-11-07 14:45) [7]

> msn777 (07.11.07 12:02) [4]

> Понятно что настоящего Real Time в Windows нет, а потоки
> необходимы для выполнения 3-х почти параллельных действий.

Почему параллельных?
Чтение - отображение - запись.

Потоки здесь (на 1 процессорной машине) - overhead.

--
Regards, LVT.

← →
msn777 (2007-11-07 15:45) [8]

> Как ты вообще собрался что-то там записывать в ОЗУ ?
> Прикладной процесс не имеет доступа к физ.памяти, только к виртуальной.

Пишу просто много для микроконтроллеров, привык память называть ОЗУ.
Запись идет в большой буфер виртуальной памяти, используемой как FIFO, с двумя указателями чтения и записи и количеством байт в FIFO, все прекрасно работает и правильно синхронизировано между собой.

> Про коллизии слышал - ты точно уверен, что у тебя запись в озу не пересечёться с чтением? И что ты кучку мусора не считаешь?.

Да уверен. За полгода работы проги нареканий не было. Коллизий нет, там где нужно используются Interlocked функции.

Вопрос был по использованию общего FilePointer в потоках, а не использовании памяти.

> Почему параллельных?
> Чтение - отображение -.

Потому что внешнее устройство работает асинхронно от ПК, пользователь работает асинхронно, а запись идет не по 1K-2K, а по 1-2МБ, т.е. может быть так:
Чтение
Чтение
Чтение
Отображение
Чтение
Чтение
Отображение
Чтение
Запись

← →
DiamondShark © (2007-11-07 16:49) [9]

> msn777 (05.11.07 15:09)

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

← →
DiamondShark © (2007-11-07 16:54) [10]

> Потоки здесь (на 1 процессорной машине) - overhead.

Без фанатизма, пожалуйста.

UI и IO -- самые лучшие кандидаты на распараллеливание по потокам не зависимо от количества процессоров. Именно по причине того, что большую часть времени эти задачи как раз не занимают процессор, а ждут реакции внешних устройств.

← →
Leonid Troyanovsky © (2007-11-07 19:49) [11]

> msn777 (07.11.07 15:45) [8]

> Потому что внешнее устройство работает асинхронно от ПК,
> пользователь работает асинхронно, а запись идет не по 1K-
> 2K, а по 1-2МБ, т.е. может быть так:

Да хоть и так. Что здесь выправят доп. потоки?

А юзера распутились, работают, понимаешь, асинхронно.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2007-11-07 19:51) [12]

> DiamondShark © (07.11.07 16:54) [10]

> Без фанатизма, пожалуйста.

Без глупостей, плиз.

--
Regards, LVT.

← →
DiamondShark © (2007-11-09 12:04) [13]

> Leonid Troyanovsky © (07.11.07 19:51) [12]

Обоснования будут, или спишем на "лапнул не подумав"?

← →
Leonid Troyanovsky © (2007-11-09 12:50) [14]

> DiamondShark © (09.11.07 12:04) [13]

Обоснования будут, или спишем на "лапнул не подумав"?

Кто первый начал, тот и первый обоснуй.

--
Regards, LVT.

← →
MetalFan © (2007-11-11 23:09) [15]

ну вот) начались переводы стрелок ;)
уж обоснуйте плиз оба! интересно почитать )))

← →
miek (2007-11-12 20:53) [16]

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

> MetalFan © (11.11.07 23:09) [15]

> уж обоснуйте плиз оба! интересно почитать )))

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

Лучше всего, IMHO, организовать было б так:
сбрасывать данные на отдельно стоящий SQL сервер,
и читать его отдельным клиентом.
Если клиент работает на одной машине с читателем,
то приоритет писателя д.б. выше.

Ну, а можно и в одном потоке: чтение, запись (синх.) и, если осталось
время (до таймера, до event) - мож что-то и покажем.

И, ясно, что 3 потока - здесь оверхед, только на переключении
контекстов. Да и, синхронизировать будет не очень удобно,
если учесть, что VCL-потоку нужно (?) приоритет понизить.

--
Regards, LVT.

> miek (12.11.07 20:53) [16]

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

Допустим, что у потоков-читателей есть r/o mapping файла,
и они писателю не мешают (мешают, конечно, мешают).
Но, и в этом случае, извещать-то их об изменениях нужно.
А двух писателей, все равно, разделять надо.

--
Regards, LVT.

> Leonid Troyanovsky (12.11.2007 21:48:18) [18]

Должна быть идеология аналогичная TMultiReadExclusiveWriteSynchronizer.

> Anatoly Podgoretsky © (13.11.07 09:00) [19]

> Должна быть идеология аналогичная TMultiReadExclusiveWriteSynchronizer.

После D5, IMHO, borland существенно переработал изначальный
вариант, написанный, видимо, двоечниками. Но, все равно,
прежде чем использовать, лучше его тщательно изучить.

Гораздо прозрачней объект Рихтера: Single writer multiply readers
guardian object (SWMRG), откуда и взять идеологию, бо, хоть он
и рассчитан на межпроцессную синхронизацию, работал гораздо
надежней чем MREWS.

--
Regards, LVT.

> Leonid Troyanovsky (13.11.2007 10:44:20) [20]

Так я с учетом конференции и не говорю, об его использовании.

Cогласовать вызов из разных потоков WriteFile ReadFile FilePointe Найти похожие ветки