ASP.NET параллелизм

Question

Пусть у меня есть a.aspx и b.aspx как с функцией е.

У меня также есть экземпляр объекта, o, который проводится в сеансе.

Каждый клиент имеет Ajax скрипты, которые требуют a.f и b.f асинхронно.

a.f называет o.ReadData

b.f называет o.ReadData

объекта, а, поддерживает один открытый дескриптор файла, из instatiation, пока он не будет удален.

Есть ли проблемы с параллелизмом при доступе к файлу в o? Почему или почему нет?

Answer 1

Если файл доступен только для чтения, у вас не будет проблем.

Миллион неисключительных читателей в одном файле не вызывает проблем. Если есть вероятность, что у одного (или более) авторов возникнет проблема, и вам необходимо заблокировать ее. Если ваш файл открывается, он захватывает эксклюзивный дескриптор файла, тогда другие открыватели не сработают. В противном случае, все в порядке.

Это так вопрос касается общей проблемы относятся: Multiple threads reading from the same file

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

Answer 2

a.aspx и b.aspx - отдельные страницы; поэтому их можно запросить параллельно, и, вероятно, это будет браузером; если оба используются вашим сценарием AJAX. Два запроса на страницу, вероятно, будут работать на двух отдельных потоках; если их запрашивают примерно в одно и то же время.

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

При любых обстоятельствах; Я бы не хотел помещать открытый файл в объект Session. Откуда вы знаете, когда закрыть файл? У вас может быть утечка ресурсов.

Answer 3

Ответ от того, что вы сказали до сих пор, «возможно».

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

Большой вопрос: как объект на сделке с его файлом. Если это используется в порядке повторного входа, тогда все в порядке. Это означает, что если в любой момент вы можете вызвать другой поток, вызывающий метод, и потому, что никакое состояние в объекте никогда не изменяется (изменяются только локальные переменные, нет экземпляра или статических членов), тогда вы в порядке.

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

Если «удерживает дескриптор файла», вы имеете в виду, что у него есть объект File, и каждый раз, когда он используется, он вызывает File.OpenRead, прежде чем удалять поток, возвращенный в тот же вызов, тогда это нормально. Если, однако, вы имеете в виду, что у вас есть поток, возвращаемый File.OpenRead, а вы Seek перед каждым чтением, то у вас есть проблема параллелизма.

В то время как для одного приложения с резьбой консоли может быть более эффективным, чтобы открыть поток с OpenReadSeek, а затем, если нужно посмотреть в начале файла снова с многопоточного приложения (и все ASP.NET является по своей сути многопоточность, даже если вы никогда явно не создаете поток), гораздо эффективнее звонить OpenRead каждый раз, когда вам нужно.