Здравствуйте, Hоmunculus, Вы писали:
H>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться?
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Hоmunculus, Вы писали:
H>>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться?
M>Нет конечно.
Здравствуйте, Hоmunculus, Вы писали:
H>>>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться?
M>>Нет конечно.
H>Это ответ на первый или на второй вопрос?
Здравствуйте, ononim, Вы писали:
H>>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться? O>А что такое хардварный поток?
Который физически распараллелен, а не перещелкиванием контекста
H>>>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться? O>>А что такое хардварный поток? H>Который физически распараллелен, а не перещелкиванием контекста
Во всех современных осях потоки сделаны перещелкиванием контекста. Физических ядер на все потоки не хватит.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
H>>>>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться? O>>>А что такое хардварный поток? H>>Который физически распараллелен, а не перещелкиванием контекста O>Во всех современных осях потоки сделаны перещелкиванием контекста. Физических ядер на все потоки не хватит.
Здравствуйте, Hоmunculus, Вы писали:
M>>После первого вопроса второй я даже не читал
H>Я так себе представляю, что разрабы стандратной библиотеки для конкретной архитектуры уже знают хардварные тонкости и все это предусмотрели.
Нет конечно. Микроконтроллеров тысячи разных, каждый со своими приколами. Даже если это ARM на Cortex-M, не уверен, что это реально. Ведь по сути в библиотеке должен быть планировщик-шедулер, который бы их переключал, все примитивы типа семафоров/мьютексов, и тд и тп. Это считай уже ядро ОС. Собственно, FreeRTOS в общем-то только это и делает, в ней не особо чего есть больше. Кто тебе это всё будет реализовывать в виде стандартной библиотеки?
Более того. Я подозреваю, что тот же GCC, которым я собираю прошивки, он о микроконтроллере вообще ничего не знает. В результате его работы на выходе получается вполне стандартный ELF, который уже потом всякими тулзами преобразуется в HEX для зашивки
O>>>>А что такое хардварный поток? H>>>Который физически распараллелен, а не перещелкиванием контекста O>>Во всех современных осях потоки сделаны перещелкиванием контекста. Физических ядер на все потоки не хватит. H>Ну по ядрам кто это распределяет? Ось? А без нее?
Планировщик задач, который в случае оси является ее частью, но по сути при программирование под голое железо вся ось по сути может собой представлять планировщик и все
Ты пишешь код под что? Под FreeRTOS или таки под какую то жирную операционку? Если первое то там скорее всего std::thread просто не реализован. Можешь реализовать, под конкретный планировщик. Если чтото пожирнее, да хотябы vxWorks, то std::thread может уже и будет работать.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Hоmunculus, Вы писали:
M>>А если нет "хардварных" потоков? А если их два, а тебе надо 10 создать?
H>Ну так вопрос в том и был — умеет ли std::thread это или нет
Ну, если бы ты задумался над вопросом: "а как бы это могло бы быть?", то вопроса бы и не было бы
M>>А если нет "хардварных" потоков? А если их два, а тебе надо 10 создать? H>Ну так вопрос в том и был — умеет ли std::thread это или нет
Этот вопрос переводится как умеет ли С++ рантайм который ты пользуешься когда компиляешь код под какую то железку запускать тред на отдельном процессоре. Я думаю можно заранее сказать что нет, но ты можешь написать такой рантайм.
Но обычно дело обстоит так: есть железо, есть ось (хотябы минималистичная, типа FreeRTOS) под это железо и есть С++ рантайм. Потоки обычно реализуются в оси, а поддержка этого АПИ в рантайме С++ — это дело десятое.
А когда потоки реализуются, то в 99.9% случаев они реализуются через переключение контекста по таймеру или хотябы кооперативно. Многопроцессорность идет к этому всему как бонус. Я хз есть ли спецось в которой потоки работали бы строго каждый на своем процессоре и никак иначе. Может и ест в узких нишах. Но врядли можно ожидать что твой С++ рантайм будет работать именно так в твоем случае. Не факт что std::thread вообще будет работать у тебя.
Кстати расскажи подробнее под что ты пишешь, может будет больше инфы из этого
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Hоmunculus, Вы писали:
H>Здравствуйте, ononim, Вы писали:
H>>>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться? O>>А что такое хардварный поток?
H>Который физически распараллелен, а не перещелкиванием контекста
Здравствуйте, Hоmunculus, Вы писали:
H>О есть какая-то гарантия что без оси создастся хардварный поток?
Даже и с осёй нет.
H>Или это самому надо руками к хардваре стучаться?
Ну у тебя или есть какой-то рантайм, который обеспечивает тебе минимальные удобства (аллокацию памяти там, илициализацию регистров, как C++ надо, потоки те же) или ты с железом один на один.
Есть "операционные системы", которые представляют собой такую большую библиотеку. Т.е., удобства есть, но полноценной оси, с процессами там и защитой памяти от них, нет.
Здравствуйте, Hоmunculus, Вы писали:
H>Я так себе представляю, что разрабы стандратной библиотеки для конкретной архитектуры уже знают хардварные тонкости и все это предусмотрели.
Вопрос в том, как найти стандартную библиотеку, рассчитанную на запуск на голом железе, а не в среде определённой оси.
И, как вариант, можно использовать полноценную ось. Они бывают не только венда и линух, но и промышленные операционные системы. Например, QNX, RTEMS...
_>если задать affinity mask, то дает, а что?
Он тогда дает гарантию что твой тред не будет работать нигде кроме указанного процессора/ов.
Но это вовсе не гарантирует что никто кроме тебя не будет работать на этом процессоре, и соответственно вызывать context switch-и.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, mike_rs, Вы писали:
_>Здравствуйте, Doom100500, Вы писали:
H>>>Который физически распараллелен, а не перещелкиванием контекста D>>А CreateThread даёт такие гарантии?
_>если задать affinity mask, то дает.
И автоматически сразы никакой другой процесс не полезет в твой афинити, да? И Переключения контекста не будет, да?
_>а что?
Здравствуйте, Hоmunculus, Вы писали:
H>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться?
Если запускать без операционной системы, то будет создан ровно один поток (в котором будет запущена main функция), он же "хардварный". Мне не известны компиляторы, которые реализуют поддержку std::thread без операционной системы. Я таким не занимался, но теоретически можно скомпилировать исходники так, чтобы полученный в результате сборки бинарник содержал в себе часть операционной системы необходимой для запуска программы и запускал эту программу при старте. Однако гарантий "хардварности" этого потока всё равно нет.
Здравствуйте, Marty, Вы писали:
H>>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться? M>Нет конечно. Как ты себе это представляешь?
Здравствуйте, Hоmunculus, Вы писали:
H>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться?
Немного оффтопну. А какой смысл писать сложные программы для голого железа? Там столько уровней абстракций, что страшно представить количество человеко-часов, чтобы реализовать хотя бы всё базовое из POSIX.
H>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться?
Гарантий нет.
Я на 98.5% уверен, что без оси ничего нет, но 1.5% — я б проверил.
Если что, то я писал ось на пустую машину.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, cppguard, Вы писали:
C>Немного оффтопну. А какой смысл писать сложные программы для голого железа? Там столько уровней абстракций, что страшно представить количество человеко-часов, чтобы реализовать хотя бы всё базовое из POSIX.
Это делается для случаев, когда от софта зависит жизнь людей: медицина, авионика и тому подобное. Поэтому всякие позиксы с лицензиями "мы ни за что не отвечаем", по законам (различных стран) не могут быть использованы.
Здравствуйте, B0FEE664, Вы писали:
BFE>Это делается для случаев, когда от софта зависит жизнь людей: медицина, авионика и тому подобное. Поэтому всякие позиксы с лицензиями "мы ни за что не отвечаем", по законам (различных стран) не могут быть использованы.
для этого берут сертифицированную ось типа qnx , а не пишут свой велосипед.
Здравствуйте, steep8, Вы писали:
S>для этого берут сертифицированную ось типа qnx , а не пишут свой велосипед.
Пишут и ещё как пишут. Во-первых в больших конторах можно переиспользовать уже существующую кодовую базу, а во-вторых штуку за разработчика в месяц за всё время жизни продукта (а это десятки лет) — получится существенная сумма.
Здравствуйте, ononim, Вы писали:
O>А когда потоки реализуются, то в 99.9% случаев они реализуются через переключение контекста по таймеру или хотябы кооперативно. Многопроцессорность идет к этому всему как бонус.
Угу.
Даже просто запустить на железке второй поток при наличии второго ядра (или более ядер и процов) — это немножко приседаний требуется, бо при запуске все остальные ядра, кроме ядра 0 процессора 0, запускаются в т.н. "состоянии сна". Эти другие процы/ядра надо разбудить через специальное прерывание, указав адрес, с которого начать исполнять код.
Далее.
Существуют различные реализации STL с поддержкой различных стандартов АПИ для различных ОС.
Если оси нет, но под контроллер есть либы создания и переключения потоков + примитивы синхронизации, то ты можешь сам написать эту часть STL, чтобы использовать, допустим, имеющийся уже готовый код в своей разработке для железки.
Здравствуйте, B0FEE664, Вы писали:
BFE>Это делается для случаев, когда от софта зависит жизнь людей: медицина, авионика и тому подобное. Поэтому всякие позиксы с лицензиями "мы ни за что не отвечаем", по законам (различных стран) не могут быть использованы.
Так POSIX это стандарт, а не продукт. QNX, например, реализует POSIX и вполне используется в таких проектах. В mission-critical задачах используется слоёный подход, и только самые нижние слои пишутся в голом железе, где нет потоков, потому что потоки это априори боль, страдания и race-conditions.
Здравствуйте, Hоmunculus, Вы писали:
H>О есть какая-то гарантия что без оси создастся хардварный поток? Или это самому надо руками к хардваре стучаться?
Без оси тебе потоки скорее всего в либу не положат. Старая традиция
