Вопросы к зачету

Green threads, файдеры, процессы в Эрланге и горутины - это одна и та же фигня?

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0

Но без участия ядра единственное, что может прервать процесс - специализированная железка.

Каким это образом, если любое взаимодействие с железом происходит через ядро?

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

Так или я что-то забыл/надо было ответить более формально.

Каким это образом, если любое взаимодействие с железом происходит через ядро?

Нет. Никто не мешает замапить память железки в адресное пространство процесса. Ядро только в начале нужно. Но с прерываниями — да, без ядра никак.

Каким это образом, если любое взаимодействие с железом происходит через ядро?

Процесс может подмапить себе память устройства и работать с ней в обход ядра. Но, как правильно заметил омороша, прерывания в любом случае ходят через ядро. Так что реализовать вытесняющую многозадачность исключительно в юзерспейсе не выйдет.

Но с прерываниями — да, без ядра никак.

Почему-то думал, что через uio таки можно повесить на прерывание свой обработчик. Но потом подумал ещё немного и понял, что лучше такого не позволять.

Процесс может подмапить себе память устройства и работать с ней в обход ядра

И как это поможет прервать исполнение?

Так что реализовать вытесняющую многозадачность исключительно в юзерспейсе не выйдет.

В первом приближении кажется что да. Хотя есть ещё инструментация кода, но тут много нужно от компилятора. Ну и можно предположить наличие на каких-то процессорных архитектурах наличие непривилегированных механизмов для прерывания исполнения - например, для профайлинга.

Процесс может подмапить себе память устройства и работать с ней в обход ядра

И как это поможет прервать исполнение?

Конкретно это никак. Я думал, что uio genirq позволяет обрабатывать прерывания в обход ядра, оказалось, что нет.

Хотя есть ещё инструментация кода, но тут много нужно от компилятора.

Именно так и делает компилятор того же го - грубо говоря, втыкает между каждой инструкцией вызов планировщика. Только если го позовёт незавершающийся сишный код, то всё встанет колом.

Ну и можно предположить наличие на каких-то процессорных архитектурах наличие непривилегированных механизмов для прерывания исполнения - например, для профайлинга.

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

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

Не, это по сути не будет отличаться от упомянутой инструментации, только сложнее и медленнее. Я не знаю как работают хардварные бряки, но предполагаю что они тоже обрабатываются через ядро. А я имел в виду другой механизм.

А системный аналитик таких вещей знать не должен?

Имхо первое что должен уметь любой аналитик так это проводить обсуждение тем, второе что он должен уметь это проводить первичный сбор материала с помощью средств индексации, таких как Yacy, Duckduckgo, Yandex, Google и пр.

цепляться за ВУЗ тебе не нужно

В вузе у многих первоочередная задача - найти мужа.

ты накрасилась?

системный аналитик должен владеть системным анализом и желательно, синтезом. лучше изучай системную инженерию.

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

конкретный технический вопрос: чем аналитик отличается от архитектора.

Они как два полицейских, один умеет читать, а другой писать?

Нет. Аналитик может вообще на другом языке говорить по твоей аналогии. Ну и по факту аналитик может на R/Python/Matlab/Octave/Julia/Scala сидеть, а проект будет на каком-нибудь С++/Java.

Нет, все кроме Эрланга управляется ОС. Эрланговский планировщит тоже управляется ОС но внутри он сам планирует процессы.

Например вот тут https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_process.c#L6769

Хоть один заметил :)

Мне кажется ты не прав. ОС управляются системные потоки, а все остальное управляется кодом рантайма внутри твоего приложения, и ОС эти потоки не видит.

ОС эти потоки не видит.

ОС знает о всех используемых ресурсах приложения и более того …

Хочешь сказать что ядро линукс что-то знает о горутинах? Сомневаюсь.

Под управляются я имею ввиду как происходит передача управления между ними. В Эрланге прикол в том что планировщик может это сделать сам в любое время.

В случае горутин/зеленых потоков эта передача более «пассивная» и происходит во время определенных вызовов, обычно это блокирующее IO, это я имею ввиду под «управляется ОС». Хотя в Го они используют несколько разных техник которые более-менее приближают к Эрланговской модели.

ОС эти потоки не видит

Не видит, собственно все приведенные подходы отличаются именно тем как они переводят внутренние процессы приложения в процессы которые понимает ОС.