В Windows приложение имам клас, който обвива име на файл и буфер. Конструирате го с име на файл и можете да направите запитване към обекта, за да видите дали буферът вече е запълнен, връщайки nullptr, ако не, и адреса на буфера, ако е така. Когато обектът излезе извън обхвата, буферът се освобождава:
class file_buffer
{
public:
file_buffer(const std::string& file_name);
~file_buffer();
void* buffer();
private:
...
}
Искам да поставя данните в паметта асинхронно и доколкото виждам, имам два избора: или да създам буфер и да използвам припокрит IO чрез ReadFileEx, или да използвам MapViewOfFile и да докосна адреса в друга нишка.
В момента използвам ReadFileEx, което създава някои проблеми, тъй като заявки, по-големи от около 16MB, са предразположени към неуспех: мога да опитам да разделя заявката, но след това получавам проблеми със синхронизирането и ако обектът изпадне извън обхвата преди IO завършен Имам проблеми с почистването на буфера. Освен това, ако множество екземпляри на класа са създадени в бърза последователност, нещата стават много трудни.
Картографирането и докосването на данните в друга нишка изглежда значително по-лесно, тъй като няма да имам проблеми с горната граница: също така, ако клиентът абсолютно трябва да има данните точно сега, той може просто да дереферира адреса, нека операционната система да се тревожи грешка на страницата и поемете блокиращия удар.
Това приложение трябва да поддържа едноядрени машини, така че въпросът ми е: грешките на страницата в друга софтуерна нишка ще бъдат ли по-скъпи от припокриването на IO в текущата нишка? Ще забавят ли процеса? Припокритият IO спира ли процеса по същия начин или има някаква магия на ОС, която не разбирам? Извършват ли се грешки в страницата с помощта на припокрит IO?
Прочетох добре тези теми: http://msdn.microsoft.com/en-us/library/aa365199(v=vs.85).aspx (IO концепции в управлението на файлове) http://msdn.microsoft.com/en-us/library/windows/desktop/aa366556(v=vs.85).aspx (съпоставяне на файлове), но изглежда не мога да заключа как да направя компромис с производителността.
