Правильный вопрос
Кто-нибудь сталкивался с этим исключением на одноядерном компьютере?
The I/O operation has been aborted because of either a thread exit or an application request.
Некоторый контекст
В системе с одним процессором одновременно выполняется только одна инструкция MSIL, независимо от потоков. Между операциями среда выполнения выполняет свою служебную работу.
Введите второй ЦП (или второе ядро), и станет возможным выполнение операции , пока среда выполнения выполняет служебную работу. В результате код, который отлично работает на машине с одним процессором, может зависнуть - или даже вызвать синий экран - при выполнении в многоядерной среде.
Интересно, что HyperThreaded Pentiums не проявляют проблему.
У меня был пример кода, который отлично работал на одном ядре и шелестел на многоядерном процессоре. Это где-то где-то, но я все еще пытаюсь найти это. Суть его заключалась в том, что, когда он был реализован как шаблон Visitor, он шелушился после непредсказуемого количества итераций, но перемещение метода в объект, с которым работал посетитель, приводило к исчезновению проблемы.
Для меня это говорит о том, что в фреймворке есть какая-то внутренняя хеш-таблица для разрешения ссылок на объекты, и в многоядерной системе существует условие гонки в отношении доступа к этому.
У меня также есть код, использующий APM для обработки последовательных сообщений. Раньше он периодически отображал синий экран в драйвере виртуального компорта для моего последовательного USB-адаптера, но я исправил это, выполняя Thread.Sleep(0) после каждого Stream.EndRead(IAsyncResult)
Через случайные интервалы, когда вызывается AsyncCallback, который я предоставляю Stream.BeginRead(...), и обработчик пытается вызвать Stream.EndRead(IAsyncResult), он выдает IOException, заявляя, что The I/O operation has been aborted because of either a thread exit or an application request.
Я подозреваю, что это также связано с многоядерностью и что какая-то внутренняя ошибка убивает поток ожидания, что приводит к такому поведению. Если я прав в этом, то у структуры есть серьезные недостатки в контексте многоядерной среды. Хотя есть обходные пути, о которых я упоминал, вы не всегда можете применять их, потому что иногда их нужно применять внутри другого кода платформы.
Например, если вы будете искать в сети описанную выше исключительную ситуацию IOException, вы обнаружите, что она влияет на код, написанный людьми, которые даже не подозревают, что используют несколько потоков, потому что это происходит под прикрытием удобных оболочек фреймворка.
Microsoft имеет тенденцию выдавать эти сообщения об ошибках как невоспроизводимые. Я подозреваю, что это связано с тем, что проблема возникает только в многоядерных системах, и в отчетах об ошибках, таких как , в этом , не упоминается количество процессоров.
Итак ... пожалуйста, помогите мне определить проблему. Если я прав в этом, мне нужно будет доказать это повторяемыми тестами, потому что то, что я считаю неправильным, повлечет за собой исправления ошибок как в фреймворке, так и во время выполнения.
Было высказано предположение, что проблема скорее в моем коде, чем в фреймворке.
Изучая вариант А проблемы, я перенес код проблемы в пример приложения и сократил его до тех пор, пока не остались только настройки потоков и вызовы методов, которые работали на одном процессоре и не работали на двух.
Вариант B Я не так проверял, потому что у меня больше нет одноядерных систем. Поэтому я повторяю вопрос: кто-нибудь видел это исключение на одноядерной платформе?
К сожалению, никто не может подтвердить мое подозрение, только опровергнуть его.
Бесполезно говорить мне, что я подвержен ошибкам, я уже знаю об этом.
Если вы знаете способ прикрепления приложения .NET к одному ЦП, это было бы очень удобно для выяснения этого. --- Спасибо за предложение VM. Я сделаю именно это, хороший звонок.