Многопоточное чтение файлов. Нужен ли критический раздел для поиска и чтения? - PullRequest
0 голосов
/ 21 июля 2011

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

stream.Seek(seekStart, SeekOrigin.Begin);
stream.Read();
stream.Seek(seekNext, SeekOrigin.Current);
stream.Read();

или

lock(fileLock)
{
    stream.Seek(seekStart, SeekOrigin.Begin);
    stream.Read();
    stream.Seek(seekNext, SeekOrigin.Current);
    stream.Read();
}

Очевидно, что я пытаюсь избежать следующей ситуации:

.
.
 Thread A: Seek
 <- Preempted ->
 Thread B: Seek
 Thread B: Read
 <- Preempted ->
 Thread A: Read  (Will this be reading from the wrong location?)
.
.

Ответы [ 4 ]

3 голосов
/ 21 июля 2011

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

Это предполагает, что вы объявляете все свои переменные в объекте класса, а не статические.

1 голос
/ 21 июля 2011

Всякий раз, когда вы изменяете объект, который является общим для потоков, вам нужен критический раздел.

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

Если у каждого потока есть собственная переменная stream (не ссылающаяся на один и тот же объект), то нет.

0 голосов
/ 22 июля 2011

MSDN скажем для FileStream "

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

Если при вызове метода Read обнаружено непредвиденное изменение позиции дескриптора, .NET Framework отбрасывает содержимое буфера и читаетпоток из файла снова. Это может повлиять на производительность, в зависимости от размера файла и любых других процессов, которые могут повлиять на положение потока файла.

Таким образом, по крайней мере, вы можете иметь производительностьпроблемы.Для повышения производительности лучшим решением является использование асинхронного ввода-вывода (BeginRead, EndRead)

0 голосов
/ 21 июля 2011

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

В качестве альтернативы вы можете использовать MemoryMappedFile (ne в .NET 4) ... thisпозволяет нескольким потокам получать к нему доступ без разделов критических значений, поскольку он отображает файл в ОЗУ, а затем вы можете получить произвольный доступ к его содержимому ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...