Я правильно понимаю, что процессы создаются вызовом fork, а треды

- облегченные процессы - вызовом clone (под капотом каких-нибудь posix-threads или аналогов, если есть)?

нет, треды ни в каком смысле не являются облегченными процессами

А чем тогда?

И процессы и thread-в используют системный вызов clone, но с разными флагами

1. Это не относится к C++ 2. в Windows нет никакого fork :)

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

По моему программирование на любом языке в том или ином виде подразумевает взаимодействие с ядром И я имел ввиду линукс

Понятно, спасибо за пояснение

с каким ядром? я на микроконтроллере один!

Еххпе ну там же сейчас тоже часто операциогнки стоят наверное) Не знаю)

Это про win?

я написал достаточно общие слова, чтобы по идее и к линуксам, и к бсд относилось (в голове при написании был линукс)

ок, а код самого ядра по-вашему из астрального плана является и его никто не программирует?

Ну это вы же докопались Большинство людей все таки не ядра программируют Но я вас понял)

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

Написали, как всегда грамотно. Просто тогда уточню, что исторически Linux не всегда поддерживал posix thread-ы, только процессы. В итоге thread-ы были реализованы на базе процессов. В Windows, насколько знаю, сразу плясали от модели, где потоки - это единица, с которой работает планировщик, а процесс - контейнер потоков.

Ни "тредов" ни "процессов" нет. Это все абстракции. Есть только поток исполнения процессора, который, к слову, никогда не останавливается. И область виртуальной памяти внутри которой все живёт.

Не совсем правильно Дело в том что Fork- это вызов специфичный для одной или нескольких операционных систем в общем Как создаются процесс с точки зрения языка c++ не определено

Вот это была хорошая попытка но неудачная Дело в том что потоки есть в рамках языка c++, есть стандартный API для их инициализации и последующей работе с ними, Ну есть Может быть не формализованная в рамках языка Но Определение потока, а если есть определение потока, то есть и определение процесса как его антагониста, Хотя общего API для создания процесса у нас в c++ пока нет

Бррр... Моё определение, а скорее видение этих сущностей более прозрачное и правильное. Всегда был против попыток оторвать с++ от железа. С++ - это язык в конечном итоге работающий на железе. Программируя на с++ нужно всегда хотя бы немного себе представлять что получится из 2+2 и из std::thread.

К слову, последнее весьма неочевидно ;)

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

https://habr.com/ru/companies/selectel/articles/525542/

о, это я умею volatile size_t i = 42; while (i++) {}

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

* многоядерный процессор смотрит с недоумением *

Не не не, вовсе не факт. А всё поведение с железом в рамках с++ скорее всего сводится к вариантам UB

Ну это некоторая концепция, которую накрутили поверх процессоров, но про которую формально процессор ничего не знает

Ох... Весьма поверхностно :)

Там гугл диктант подглючил, я имел в виду что определение потока в рамках языка есть, а процесса - нет, и API нет для процессов

Ты на срок себе не наговори

https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/16_Waking_and_Sleeping/sleeping-states.html

Я Вас прекрасно понимаю. В первом классе школы, когда дети изучают таблицу умножения, нужно ли упомянуть о Гильбертовых пространствах и интегрированию по Лебегу? Некоторые преподаватели для простоты просто отметают эту "ересь". Я с таким подходом не согласен. Нужно это все упомянуть. И таблице умножения учить надо и перспективы раскрывать тоже.

Всегда есть уровень ниже. Под логикой физика твердого тела и т.д. )

интегралы по лебегу надо рассказать тогда, когда чел их сможет осознать

Зря, это - единственно правильный подход.

Перспективы раскрывать надо, да...

У меня есть заочка по практической психологии. Исходя из этих компетенций могу говорить что.. Способности к абстрактному мышлению проявляются у человеческого существа в период от 22-х до 45-лет. У всех по разному. Очень и очень редко раньше и очень и очень редко позже. Многие просто живут, едят и срут не проявляя никакой способности. Искры божьей нет. Но! В отношении тех у кого эта божья искра есть можно воздействовать, чтобы она проявилась раньше! Мы все дети своей генетики от родителей, но и воспитания от воздействия своего окружения. Поэтому, если бить, пинать, объяснять, и всячески заставлять думать, - умных будет больше.

ЛеЧака знаю, Лебега — не слышал такого

что за лечак

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

Может, тут смогут ответить?

1) в рамках стандартной модели нет никакого железа 2) вы расскажете плохо 3) скорее всего ещё покажете сишный стиль, вместо адекватного

Нужно упомянуть вещи, которые напрямую не влияют на написание кода, а являются бесполезной информацией. Во время обучения нужно показывать полезные вещи: ну банально рассказать про кеши и тот факт, что если ты хранить std::vector<Data> - это кеш дружелюбно, если std::vector<unique_ptr<Data>>, то это уже одна индерекция, что больно, если std::vector<std::variant<Data1, Data2>>, то опять кеш дружелюбно, но есть другие затраты на

GSL?