Виртуаьная машина не прокатит. Сейчас в винде и так введена концепция виртуализации устройств. От дедлоков это не спасает.
Фреймворк этим заниматься не может в принципе без большущего и сложненного драйвера режимя ядра, который бы перехватывал и редиспетчеризировал все системные вызовы обращений к обьектам ядра и строил бы граф зависимостей по потокам, да еще и управлял бы им. Еще нужно не забывать про вытесняющую многозадачность. При том бы 50% процессорного времени уходило бы на работу этого драйвера. Т.к. фактически любая операция ввода-вывода сопряжена с некоторым объектом ядра...
Ну на счет стека... Брать указатели на стековые переменные и передавать их во вне без приостановки потока любят начиающие программисты. Тот, кто понимает как всё работает, так никогда не поступит.
Думаю что в существующих ОС напрямую от потоков отказаться не выйдет. Для этого нужно целиком менять всю концепцию ОС. И фреймворком тут не отделаешься... Нужно делать .NET OS.
>Почему-то все забывают про процессы. Это гораздо более удобный метод
>организации многозадачной обработки, чем нити. И гораздо более
>эффективный в реализации в ядре операционной системы. У процессов много
>достоинств, а единственный недостаток - это сложность переключения
>контекста виртуальной памяти. Но в нормальных процессорах поддержка уже
>давным давно сделана на аппаратном уровне через идентификаторы
>виртуальных адресных пространств. На ненормальных, то есть, производных
>от x86, проблема решается через хитрые кэши первого уровня.
Бред вы полный написали. Процессы не исполняются. Процесс - среда для потоков. Процесс жив до тех пор пока в нем есть хотя бы один поток. Не надо забывать, что контест процесса удовольствие дорогое, намного более дорогое чем контекст потока.
>Процессы снимают проблему со стеками и со сборкой мусора, вполне
>естественным образом: стеки различны, а при завершении процесса все
>занимаемые ресурсы можно освободить.
Чего за бред про стеки? У каждого потока свой стек (под виндой даже 2). С этим проблем никаких нет.
Товарищи! Ну кто вам сказал, что в современных ЯВУ нет средств неявного обращения с потоками? Для примера возьмем C#. Вводится понятие пула потоков. Для каждого процесса создается пул рабочих потоков. Причем обращение к ним происходит неявно, посредством вызова Delegate.BeginInvoke/EndInvoke. Подробней читаем тут:
http://www.codeproject.com/csharp/AsyncMethodInvocation.asp
Такая концепция коренным образом отлична от классической. В классической модели программист явно указывает набор комманд, и поток в котором этот набор должен выполняться. Такой подход противоречит самой идее масштабируемости приложения под любое число ядер. Напротив, в концепции с пулом потоков, заранее не предопределено в каком потоке будет выполняться та, или иная подпрограмма. Есть один или несколько "главных" потоков, которые раздают некоторому множеству "рабочих" потоков очереди заявок на выполнение операций. Такой подход хорош во всем. Скажем если ядра в процессоре 2, то нет смысла держать больше 2х рабочих потоков. А если 16, то есть и еще какой.
Теперь про классический Win32 и C++. В самом языке С++ нет встроенных конструкций организации пула потоков. Однако WinAPI предоставляют подмножество функций user-mode APC (Asynchronous Procedure Calling) для задания очереди асинронных операций для потока. Используя APC, можно создать пул потоков без каких либо затруднений. Именно на этой концепции и держится часть механизма обработки прерываний - DPC - суть тот же APC, толко режима ядра и при повышенном IRQL.
Однако никакие концепции и абстракции не решат проблему синхронизации доступа к ресурсам и исключения взаимоблокировок. Конечно можно разработать общий способ, как например в C# ключевое слово lock(...). Однако всё равно компилятор никогда сам не определит точные блоки кода, на которые надо ставить блокировку, т.е. критические секции сам не расставит. Это оочень интеллектуальная задача. Можно конечно лочить всё подрад, но производительность в таком случае упадет капитально. Всё равно синхронизацию должен будет определять программист.
Если кто-то еще не читал, крайне рекомендую. Ссылка на список переведенных статей.
Фреймворк этим заниматься не может в принципе без большущего и сложненного драйвера режимя ядра, который бы перехватывал и редиспетчеризировал все системные вызовы обращений к обьектам ядра и строил бы граф зависимостей по потокам, да еще и управлял бы им. Еще нужно не забывать про вытесняющую многозадачность. При том бы 50% процессорного времени уходило бы на работу этого драйвера. Т.к. фактически любая операция ввода-вывода сопряжена с некоторым объектом ядра...
>организации многозадачной обработки, чем нити. И гораздо более
>эффективный в реализации в ядре операционной системы. У процессов много
>достоинств, а единственный недостаток - это сложность переключения
>контекста виртуальной памяти. Но в нормальных процессорах поддержка уже
>давным давно сделана на аппаратном уровне через идентификаторы
>виртуальных адресных пространств. На ненормальных, то есть, производных
>от x86, проблема решается через хитрые кэши первого уровня.
Бред вы полный написали. Процессы не исполняются. Процесс - среда для потоков. Процесс жив до тех пор пока в нем есть хотя бы один поток. Не надо забывать, что контест процесса удовольствие дорогое, намного более дорогое чем контекст потока.
>Процессы снимают проблему со стеками и со сборкой мусора, вполне
>естественным образом: стеки различны, а при завершении процесса все
>занимаемые ресурсы можно освободить.
Чего за бред про стеки? У каждого потока свой стек (под виндой даже 2). С этим проблем никаких нет.
Товарищи! Ну кто вам сказал, что в современных ЯВУ нет средств неявного обращения с потоками? Для примера возьмем C#. Вводится понятие пула потоков. Для каждого процесса создается пул рабочих потоков. Причем обращение к ним происходит неявно, посредством вызова Delegate.BeginInvoke/EndInvoke. Подробней читаем тут:
http://www.codeproject.com/csharp/AsyncMethodInvocation.asp
Такая концепция коренным образом отлична от классической. В классической модели программист явно указывает набор комманд, и поток в котором этот набор должен выполняться. Такой подход противоречит самой идее масштабируемости приложения под любое число ядер. Напротив, в концепции с пулом потоков, заранее не предопределено в каком потоке будет выполняться та, или иная подпрограмма. Есть один или несколько "главных" потоков, которые раздают некоторому множеству "рабочих" потоков очереди заявок на выполнение операций. Такой подход хорош во всем. Скажем если ядра в процессоре 2, то нет смысла держать больше 2х рабочих потоков. А если 16, то есть и еще какой.
Теперь про классический Win32 и C++. В самом языке С++ нет встроенных конструкций организации пула потоков. Однако WinAPI предоставляют подмножество функций user-mode APC (Asynchronous Procedure Calling) для задания очереди асинронных операций для потока. Используя APC, можно создать пул потоков без каких либо затруднений. Именно на этой концепции и держится часть механизма обработки прерываний - DPC - суть тот же APC, толко режима ядра и при повышенном IRQL.
Однако никакие концепции и абстракции не решат проблему синхронизации доступа к ресурсам и исключения взаимоблокировок. Конечно можно разработать общий способ, как например в C# ключевое слово lock(...). Однако всё равно компилятор никогда сам не определит точные блоки кода, на которые надо ставить блокировку, т.е. критические секции сам не расставит. Это оочень интеллектуальная задача. Можно конечно лочить всё подрад, но производительность в таком случае упадет капитально. Всё равно синхронизацию должен будет определять программист.