Embedded OS - процессы или потоки? задачи!

Hello Oleksandr.

AB>> Да, еще. Hаверное стоит как и в больших системах разделять AB>> процессы и потоки. То чем мы пользуемся в РТОС - это потоки (общее AB>> адресное пространство). OR> Hе был бы столь категоричен. Если у тебя пара "задач" общается OR> только через сервисы ОС типа семафоров/почтовых ящиков/etc, то *они* OR> не знают - в одном адресном пространстве они или нет.

Они то не знают. Hо я то знаю ;) Все равно они работают в одном адресном пространстве. Hеважно, чем они пользуются.

OR> Если они пользуются для общения и синхронизации только осевыми API, OR> то при реализации того же API, но на процессоре с MMU - физически один OR> и тот же исходный текст "задачи" надо будет назвать уже не "потоком", OR> а "процессом"?

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

OR> Почему? Что поменялось в самой "задаче"?

Да в задаче-то ничего. В самой системе поменялось.

Alexey

Hello, Oleksandr! You wrote to Alexey Boyko snipped-for-privacy@p208.f.n4624.z2.fidonet.org> on Fri, 18 Mar 2005 05:24:42 +0000 (UTC):

OR> Если они пользуются для общения и синхронизации только осевыми API, OR> то при реализации того же API, но на процессоре с MMU - физически OR> один и тот же исходный текст "задачи" надо будет назвать уже не OR> "потоком", а "процессом"? Почему? Что поменялось в самой "задаче"?

Мне кажется, что вопрос не только и не столько в API и/или наличии MMU, а скорее в _возможности_ шалить _на_ _уровне_ _исходников_ в _общем_ адресном пространстве. Если глобальные переменные разделяются - это потоки. Если же к чужим переменным можно получить физический доступ, но только путём трюков, а линкер нервно курит в сторонке - это процессы. Ы?

With best regards, Alexander Derazhne

AB>>> Да, еще. Hаверное стоит как и в больших системах разделять AB>>> процессы и потоки. То чем мы пользуемся в РТОС - это потоки (общее AB>>> адресное пространство). OR>> Hе был бы столь категоричен. Если у тебя пара "задач" общается OR>> только через сервисы ОС типа семафоров/почтовых ящиков/etc, то *они* OR>> не знают - в одном адресном пространстве они или нет.

AB> Они то не знают. Hо я то знаю ;) Какая разница что именно знаешь ты? Вот дадут тебе API к сервисам ОС и скажут - "напиши процесс". Ты напишешь. А его возьмут - и скомпилируют с ядром ОС без управления памятью - и твой процесс волшебным образом превратится в поток?

AB> Все равно они работают в одном адресном пространстве. Hеважно, чем они AB> пользуются. Он не стал пользоваться глоблаьными переменными для общения с остальными задачами, у него есть только локальные переменные и "осевые" каналы общения с остальными задачами. Почему он вдруг перестал быть процессом? Более того, выполним его в виде загружаемого модуля. Загрузчик ОС его считывает откуда-то, привязывает к конкретным адресам его внутренние ссылки (не весь же код - PIC), привязывает к адресам сервисов ОС (если они не через EMT/SWI/INT и подобные команды сделаны). Берём реализацию этой ОС с защитой памяти - и загружаемый бинарник становится процессом, берём реализацию без защиты - и он становится потоком. Как это? До тех пор, пока в программе не вылезет ошибка (или целенаправленные попытки лезть в "не те" адреса :-) - поведение каждой задачи и системы в целом не зависит от наличия защиты памяти. Почему по-разному должны называться одинаковые куски кода? Шпион <-> разведчик?

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

OR>> Почему? Что поменялось в самой "задаче"?

AB> Да в задаче-то ничего. В самой системе поменялось. Ну так если в задаче не поменялось ничего, то и её статус (процесс/поток) не изменился.

"если что-то выглядит как кошка и ведёт себя как кошка - то это кошка".

wbr,

Hello Oleksandr.

OR>>> *они* не знают - в одном адресном пространстве они или нет. AB>> Они то не знают. Hо я то знаю ;) OR> Какая разница что именно знаешь ты? OR> Вот дадут тебе API к сервисам ОС и скажут - "напиши процесс". OR> Ты напишешь. А его возьмут - и скомпилируют с ядром ОС без управления OR> памятью - и твой процесс волшебным образом превратится в поток?

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

OR> Он не стал пользоваться глоблаьными переменными для общения с OR> остальными задачами, у него есть только локальные переменные и OR> "осевые" каналы общения с остальными задачами. Почему он вдруг OR> перестал быть процессом? Более того, выполним его в виде загружаемого OR> модуля. Загрузчик ОС его считывает откуда-то, привязывает к конкретным OR> адресам его внутренние ссылки (не весь же код - PIC), привязывает к OR> адресам сервисов ОС (если они не через EMT/SWI/INT и подобные команды OR> сделаны). Берём реализацию этой ОС с защитой памяти - и загружаемый OR> бинарник становится процессом, берём реализацию без защиты - и он OR> становится потоком. Как это?

Да нет. Так как ты описал - это все равно процесс. Ключевой момент - не защита памяти. Hа 8086 можно сделать несколько процессов и без защиты памяти.

OR> памяти. Почему по-разному должны называться одинаковые куски кода?

Да не куски кода. В больших ОС работают несколько процессов с разделенной памятью, в каждом из которых работает несколько (больше 0) потоков внутри одного адресного пространства процесса.

OR>>> Почему? Что поменялось в самой "задаче"? AB>> Да в задаче-то ничего. В самой системе поменялось. OR> Hу так если в задаче не поменялось ничего, то и её статус OR> (процесс/поток) не изменился.

С самого я начала хотел сказать то, что всякие uC/OS, FreeRTOS, scmRTOS и пр. больше похожи на менеджеры потоков, а не процессов. Hе важно, используют запущенные потоки особенность работы в одном адресной пространстве или нет. Как минимум, надо не забывать, что АП все таки одно, и нельзя в разных потоках использовать одну и ту же переменную для хранения разных данных разных потоков.

Alexey

OR>> Если они пользуются для общения и синхронизации только осевыми API, OR>> то при реализации того же API, но на процессоре с MMU - физически OR>> один и тот же исходный текст "задачи" надо будет назвать уже не OR>> "потоком", а "процессом"? Почему? Что поменялось в самой "задаче"?

AD> Мне кажется, что вопрос не только и не столько в API и/или наличии MMU, AD> а скорее в _возможности_ шалить _на_ _уровне_ _исходников_ в _общем_ AD> адресном пространстве. Если "шалить" - это пулять по шальному указателю, то вопрос как раз в MMU. Если API нет никакого, то без *явного* топтания по общим областям памяти не обойтись.

AD> Если глобальные переменные разделяются - это потоки. AD> Если же к чужим переменным можно получить физический доступ, но только А как же с shared memory для ускорения межпроцессного взаимодействия? Процессы, получившие через API доступ к одной области памяти становятся потоками?

AD> путём трюков, а линкер нервно курит в сторонке - это процессы. Линкер нервно курит в сторонке, если я для каждой выполняемой под uC/OS или под SCMRTOS задачи сделаю отдельный файл и все переменные обзову static, все внешние связи сделаю только через API. Да, без MMU я из этих задач потенциально могу играть в "морской бой" с памятью других процессов. Но мы ведь не про развлечения самих-себе-злобных-буратин говорим?

AD> Ы?

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

Как по мне, то "процесс" <-> "поток" - это следование той или иной модели при написании кода, а не аппаратно-программные средства ограничения выхода за эту модель (которые есть лишь средство облегчения обнаружения ошибок в реализации модели и ограничения распространения их действия вширь). $(SUBJ) - для предотвращения рецидивов терминологических споров к процессам embedded OS предлагаю применять более нейтральный термин "задача" (task) :-)

wbr,

Hello, Oleksandr! You wrote to "Alexander Derazhne" snipped-for-privacy@i.com.ua> on Sat, 19 Mar 2005

OR>>> Если они пользуются для общения и синхронизации только осевыми OR>>> API, то при реализации того же API, но на процессоре с MMU - OR>>> физически один и тот же исходный текст "задачи" надо будет назвать OR>>> уже не "потоком", а "процессом"? Почему? Что поменялось в самой OR>>> "задаче"?

AD>> Мне кажется, что вопрос не только и не столько в API и/или наличии AD>> MMU, а скорее в _возможности_ шалить _на_ _уровне_ _исходников_ в AD>> _общем_ AD>> адресном пространстве. OR> Если "шалить" - это пулять по шальному указателю, то вопрос как раз OR> в MMU. OR> Если API нет никакого, то без *явного* топтания по общим областям OR> памяти не обойтись.

AD>> Если глобальные переменные разделяются - это потоки. AD>> Если же к чужим переменным можно получить физический доступ, но AD>> только OR> А как же с shared memory для ускорения межпроцессного OR> взаимодействия? OR> Процессы, получившие через API доступ к одной области памяти OR> становятся потоками?

AD>> путём трюков, а линкер нервно курит в сторонке - это процессы. OR> Линкер нервно курит в сторонке, если я для каждой выполняемой под OR> uC/OS или под SCMRTOS задачи сделаю отдельный файл и все переменные OR> обзову static, все внешние связи сделаю только через API. OR> Да, без MMU я из этих задач потенциально могу играть в "морской OR> бой" с памятью других процессов. Но мы ведь не про развлечения OR> самих-себе-злобных-буратин говорим?

OR> А если задача не знает - может она получить физический доступ или OR> не может, ибо просто не пробовала? Получается, "честный" OR> процесс никогда и не узнает, что он не процесс, а поток? OR> Или "честный человек" - это возле которого милиционер стоит, а как OR> милиция отошла - так сразу честным быть перестаёт? Причём так даже в OR> том случае, когда человек не видел ни присутствия милиции, ни её OR> ухода?

OR> Как по мне, то "процесс" <-> "поток" - это следование той или иной OR> модели при написании кода, а не аппаратно-программные средства OR> ограничения выхода за эту модель (которые есть лишь средство OR> облегчения обнаружения ошибок в реализации модели и ограничения OR> распространения их действия вширь).

Так а я о чём?! (Сорри, квота большая, но хотелось сохранить весь контекст). Допустим есть некий хидер, в котором описана глобальная переменная extern int var; . Или функция. Если мы можем к ней обратиться и в одном "потоке" и в другом, то это таки потоки одного процесса. Если в одном из "потоков" нужно сначала в рантайме узнать где она находится (причём в результате может оказаться что её не существует), то этот поток выполняется в рамках другого процесса.

OR> $(SUBJ) - для предотвращения рецидивов терминологических споров к OR> процессам embedded OS предлагаю применять более нейтральный термин OR> "задача" (task) :-)

Для обозначения действий "потока", не привязываясь к реализации? Консенсус.

P.S. Перечитал ещё раз. В моей интерпретации получается, что процесс - выходная единица сборки. Другие единицы могут менятся, могут вообще не включаться в оконечный бинарник (ради которого, собственно, всё и затевается). После этого могут возникать ошибки и исключения в рантайме (кто-то кого-то не нащупал), но в инструментальной фазе это не должно вызывать ошибок. Вот что такое процессы (IMHO, разумеется).

With best regards, Alexander Derazhne

Sat, 19 Mar 2005 18:14:23 +0000 (UTC) Oleksandr Redchuk wrote to "Alexander Derazhne" snipped-for-privacy@i.com.ua>:

OR> Как по мне, то "процесс" <-> "поток" - это следование той или иной OR> модели при написании кода, а не аппаратно-программные средства OR> ограничения выхода за эту модель (которые есть лишь средство облегчения OR> обнаружения ошибок в реализации модели и ограничения распространения OR> их действия вширь).

OR> $(SUBJ) - для предотвращения рецидивов терминологических споров OR> к процессам embedded OS предлагаю применять более нейтральный термин OR> "задача" (task) :-)

Спор о терминах. К чему он? Какая разница, как это называется? Деление процесс/поток имеет смысл, например, на PC, где есть защищенный режим работы с памятью. Там такое деление _необходимо_.

На мелких ОС совершенно все равно, как называть - по сути это просто отдельный кусок программы, работающий квазипараллельно и асинхронно по отношению к другим таким же кускам. Поэтому процесс, поток, задача - по большому счету не важно. Хотя, имхо, слово "поток" отдает некоей временностью - т.е. нечто такое, что создали для выполнения действий, после завершения этих действий оно прибивается. А когда оно работает длительное время без выхода - это как-то имхо больше похоже на процесс (не зря же говорят "находиться в процессе чего-то", а не "находиться в потоке чего-то" :). Т.е.

for(;;) { ... }

имхо, больше соответствует семантике слова "процесс" (или задача), нежели "поток".

Слово "процесс" означает значительно более широкий класс понятий, чем просто работа в отдельном адресном пространстве. Есть такая вытесняющая RTOS proc (от Нильсена), где используется термин process - и название от этого образовано. В языке VHDL тоже есть process, хотя это совсем не ЯП, но смысл где-то перекликается.

Т.ч. не в названии дело, а в сути, которая сводится к тому, что в контексте эхотага все мелкие RTOS используют примерно одно и то же. Что касается путаницы и терминов, то и тут все упирается в личные субъективные предпочтения - мне вот, например, слово "задача" никак не импонирует в качестве термина. Может английское слово task имеет оттенок именно задачи-процесса, но в русском языке "задача" лично у меня ассоциируется с тем, что дочка решает по математике. :)

Да и проблемы-то нет: лично у меня ни разу не возникло вопроса в обсуждении или прочтении, что означают "процесс", "поток" или "задача" - когда знаешь, о чем идет обсуждение, понятно, что имеется в виду.

Hello Alexander.

AD> Так а я о чём?! (Сорри, квота большая, но хотелось сохранить весь AD> контекст). Допустим есть некий хидер, в котором описана глобальная AD> переменная extern int var; . Или функция. Если мы можем к ней AD> обратиться и в одном "потоке" и в другом, то это таки потоки одного AD> процесса. Если в одном из "потоков" нужно сначала в рантайме узнать AD> где она находится (причём в результате может оказаться что её не AD> существует), то этот поток выполняется в рамках другого процесса.

Если это разные процессы, то обратиться к этой переменной также можно. Hо это будет доступ к разным экземплярам этой переменной.

OR>> $(SUBJ) - для предотвращения рецидивов терминологических споров OR>> к процессам embedded OS предлагаю применять более нейтральный OR>> термин "задача" (task) :-)

AD> Для обозначения действий "потока", не привязываясь к реализации? AD> Консенсус.

Можно и так.

Alexey