Ответ из того, что вы сказали до сих пор, "вероятно".
Обратите внимание, что вам даже не нужна эта ситуация двух разных файлов ASPX, два запроса к одному и тому же файлу ASPX будут иметьта же проблема, поскольку каждый ASPX-файл может обрабатывать несколько одновременных запросов.
Большой вопрос в том, как объект обрабатывает свой файл.Если он используется повторно, то это нормально.Это означает, что если в какой-то момент у вас может быть другой поток, вызывающий метод, и поскольку никакое состояние в объекте никогда не изменяется (меняются только локальные переменные, нет экземпляров или статических членов), то у вас все в порядке.
Если нет, то вам нужно заблокировать методы, о которых идет речь.Однако блокировка создает узкое место в потоке.Даже если никогда не будет тупиковой ситуации, запросы будут помещаться в очередь на этом этапе, и если метод не сможет снять блокировку быстрее, чем поступят новые запросы, задержка, вызванная этой очередью, будет становиться все больше и больше, пока не станет серьезной проблемой.
Если под «содержит дескриптор файла», вы имеете в виду, что у него есть объект File, и он вызывает File.OpenRead каждый раз, когда его используют, перед удалением потока, возвращенного в том же вызове, то этохорошо.Однако, если вы имеете в виду, что у вас есть поток, возвращаемый File.OpenRead, а вы Seek перед каждым чтением, то у вас возникает проблема параллелизма.
Хотя для однопоточного консольного приложения это может быть более эффективнымоткрыть поток с помощью OpenRead, а затем Seek, если вам нужно снова посмотреть на начало файла, с многопоточным приложением (и весь ASP.NET по своей сути является многопоточным, даже если вы никогда явно не создаете поток)гораздо, гораздо эффективнее звонить OpenRead каждый раз, когда вам нужно.