-
- Вопрос чутка некорректный и вот почему. "Mutex" - понимается как
mutual exlusion вообще, в целом. Многие без достаточных на то
оснований полагают что Mutex это всенепременно объект "операционной
системы" и отсюда делается дальнейший вывод что гарантированно
нужна операционная система. Но это не так. Mutex это общее понятие,
никакой гарантии семантики или гарантированного интерфейса у этого
термина нет. В Microsoft операционке в API для межпроцессной
синхронизации RxTx(1490 знак., 11.06.2020 18:08)
- Потому, что мьютекс может быть вообще не объект операционки, а C-библиотеки (как в linux). Но суть-то в одном, без операционки, которая может переключить потоки, мьютексы, семафоры, условные переменные -- всё теряет смысл. Потому, что с одной стороны, треду остановившемуся на уже занятом мьютексе (семафоре...) -- некуда деваться, если он будет в цикле проверять мьютекс не освобождая процессор -- это называется spinlock. Который обладает в целом меньшей реактивностью, чем fk0(1633 знак., 11.06.2020 18:50)
- Очень грамотно описано. Вы где то преподаете? - Visitor(11.06.2020 18:18)
- Благодарю, нигде сейчас не преподаю, просто хотелось помочь
человеку. RxTx(120 знак., 11.06.2020 21:01)
- Стиль текста качественный. Редко такое вижу. Радует. - Visitor(11.06.2020 21:35)
- Благодарю, нигде сейчас не преподаю, просто хотелось помочь
человеку. RxTx(120 знак., 11.06.2020 21:01)
- Вы смешали бульдога с носорогом и не хотите это понять :) Mutex -
это не из ИАРа (Там его нет и быть не может), это совсем из другого
места :). Чтобы изобрести rtos нужен хороший план и много времени.
Берите готовую: ucos, protothreaads, freertos, mainloop, rtems :)),
выпиливайте из них ненужное или наоборот. - Xитpый Kитaeц(11.06.2020 09:52)
- IAR C/C++ Development Guide. Compiling and Linking for
STMicroelectronics’ STM8 Microcontroller Family BlackMorda(555 знак., 11.06.2020 11:19, ссылка)
- Говорить о семафорах или мьютексах без операционки -- бессмысленно.
Потому как их применение подразумевает побудку процессов ожидающих
данного семафора или мьютекса. И передачу управления другим
потокам/задачам при занятости ресурса (yield). Что нельзя сделать
без взаимодействия с ОС. Без ОС возможен только спинлок. - fk0(11.06.2020 11:30)
- Вы пошатнули мою веру в IAR. Как жить дальше? ;-) BlackMorda(93 знак., 11.06.2020 12:55)
- Механизм доступа к общему ресурсу подразумевает, что кто-то иногда
его не будет получать и будет переходить в состояние ожидания, не
мешая работать остальным. Тут и возникает ОС, или ее эквивалент. - AlexBi(11.06.2020 16:48)
- Ну и зачем городить целую ОС, если я хочу самостоятельно разрулить
данную ситуацию? - BlackMorda(12.06.2020 08:20)
- Не захватывайте ресурс в прерывании и проблем с множественным доступом не будет никаких. - Xитpый Kитaeц(12.06.2020 09:53)
- Например, кооперативная ось или protothreads, где атомарность
никому не нужна. - SciFi(11.06.2020 17:26)
- КО намякивает, что реализация мутекса для protothreads, для кооперативной оси и для вытесняющей оси - будет разная, и (соответственно) не может быть фичей компилятора. Топикстартер же, вместо написания пяти строчек кода, начал требовать странного и развел турусы на колесах. - LightElf(11.06.2020 18:54)
- В protothreads мютексом будет просто любая булевская переменная
(или битовый флаг, пофиг), даже volatile не обязателен. Проблема
лишь в том, что любая система с обработчиком прерываний - уже
вытесняющая многозадачность. - lloyd(11.06.2020 18:05)
- Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же
самое, что конечные автоматы им. Шалыто, switch-технология. Удобней
представлять в виде big loop всё-таки. Идея в том, что какой-то
"протопоток", "автомат", отдал управление обратно циклу и он
побежал вызывать остальные "протопотоки" или автоматы... fk0(4542 знак., 11.06.2020 19:54, ссылка, ссылка)
- >наподобии планировщика libevent lloyd(89 знак., 11.06.2020 21:15)
- Не соглашусь. В случае оптимальной реализации автомата он входит в
состояние ожидания продолжения работы, и делает только это. Кроме
того, никто не заставляет по одному кругу крутить все автоматы. - VLLV(11.06.2020 20:37)
- В состоянии ожидания он постоянно проверяет некоторую переменную.
Если переменных много, когда параллельных/независимых автоматов
много -- эти проверки оказываются чрезмерно длительными. Вложенные
КА (в терминологии switch-технологии Шалыто) отчасти спасают
ситуацию, но в целом проблема остаётся: сильно параллельные задачи
методом big loop, switch-технологие, с помощью protothreads --
эффективно не решаются. При том, что с ними элементарно справится
планировщик типовой RTOS. - fk0(11.06.2020 20:45)
- Вызов вложенных автоматов можно организовать с разной частотой,
соответсвующей необходимой скорости обработки. Это исключит тупую
проверку. Да, сильно параллельные ДОЛГОВРЕМЕННЫЕ задачи сложно
реализовать методом биглуп, но я за свою жизнь с этим столкнулся
только в одном проекте из десятков. А ресурсы нужно делить в каждом
втором. - VLLV(11.06.2020 21:27)
- Это уже пошли костыли и подпорки. Я хотел акцентировать внимание на
проблеме, что bigloop плохо масштабиуется. Он хорош пока маленький,
когда становится большой -- он еле ворочается. Как и прототреды,
как и switch-технология. По сути это всё одно и то же. Чтоб
ворочалось побыстрее нужен какой-то механизм, планировщик, который
будет знать кому какие события интересны и вызывать обработчик
события по факту его получения (а не опрашивать каждое событие в
цикле из обработчика fk0(37 знак., 11.06.2020 23:37)
- У события делать список задач, ожидающих события? И, вестимо, у них есть приоритеты. - Dingo(15.06.2020 17:38)
- Такой планировщик называется системой прерываний, и это прослойка есть и в биглупе и в ОС. - VLLV(12.06.2020 04:48)
- Это уже пошли костыли и подпорки. Я хотел акцентировать внимание на
проблеме, что bigloop плохо масштабиуется. Он хорош пока маленький,
когда становится большой -- он еле ворочается. Как и прототреды,
как и switch-технология. По сути это всё одно и то же. Чтоб
ворочалось побыстрее нужен какой-то механизм, планировщик, который
будет знать кому какие события интересны и вызывать обработчик
события по факту его получения (а не опрашивать каждое событие в
цикле из обработчика fk0(37 знак., 11.06.2020 23:37)
- А зачем, блядь он ее проверяет?! Пусть не проверяет, пусть выберет десяток,
случайным образом, будет быстро. Мужики, так нельзя. Если технически возможно аппаратное выявление изменения состояния входов автомата (АКА
прерывание), то это можно использовать, а если нет - можно только
то, что можно. Cкpипaч(222 знак., 11.06.2020 20:52)
- Со switch-технологией наверняка знаком? А что ему делать -- там
автомат следит за своими входами и, что более важно, может
изменение переменной состояния другого автомата воспринимать как
свой входной сигнал. Последнее принципиально важно, т.к. является
одним из способов коммуникации автоматов между собой (второй способ
работает только на передачу информации -- прямой вызов функции
автомата с передачей номера входного сигнала). И если у нас есть
множество параллельных fk0(968 знак., 11.06.2020 21:18)
- Организуйте очередь событий и отстаньте от совы. - Cкpипaч(11.06.2020 21:46)
- И получится Quantum Leap он же state-machine.com. И сразу будут
спрашивать, "а что если очередь событий переполнится". И ведь
переполняется бывает. С очередью есть одна принципиальная проблема:
события из очереди обрабатываются в порядке очереди. И если она
одна на всё, то возможен "шторм событий", когда некоторые события
попавшие на вход генерируют достаточно большое количество
внутренний событий, и так рекурсивно. И если на вход поступает
сразу много "проблемных" событий, fk0(815 знак., 11.06.2020 23:34)
- Стоп. Основная идея машины состояний - разделение входов, выходов и не-асинхронность. Иначе гонки можно и без очередей получить. Cкpипaч(1079 знак., 12.06.2020 10:12)
- И получится Quantum Leap он же state-machine.com. И сразу будут
спрашивать, "а что если очередь событий переполнится". И ведь
переполняется бывает. С очередью есть одна принципиальная проблема:
события из очереди обрабатываются в порядке очереди. И если она
одна на всё, то возможен "шторм событий", когда некоторые события
попавшие на вход генерируют достаточно большое количество
внутренний событий, и так рекурсивно. И если на вход поступает
сразу много "проблемных" событий, fk0(815 знак., 11.06.2020 23:34)
- Организуйте очередь событий и отстаньте от совы. - Cкpипaч(11.06.2020 21:46)
- Со switch-технологией наверняка знаком? А что ему делать -- там
автомат следит за своими входами и, что более важно, может
изменение переменной состояния другого автомата воспринимать как
свой входной сигнал. Последнее принципиально важно, т.к. является
одним из способов коммуникации автоматов между собой (второй способ
работает только на передачу информации -- прямой вызов функции
автомата с передачей номера входного сигнала). И если у нас есть
множество параллельных fk0(968 знак., 11.06.2020 21:18)
- Вызов вложенных автоматов можно организовать с разной частотой,
соответсвующей необходимой скорости обработки. Это исключит тупую
проверку. Да, сильно параллельные ДОЛГОВРЕМЕННЫЕ задачи сложно
реализовать методом биглуп, но я за свою жизнь с этим столкнулся
только в одном проекте из десятков. А ресурсы нужно делить в каждом
втором. - VLLV(11.06.2020 21:27)
- В состоянии ожидания он постоянно проверяет некоторую переменную.
Если переменных много, когда параллельных/независимых автоматов
много -- эти проверки оказываются чрезмерно длительными. Вложенные
КА (в терминологии switch-технологии Шалыто) отчасти спасают
ситуацию, но в целом проблема остаётся: сильно параллельные задачи
методом big loop, switch-технологие, с помощью protothreads --
эффективно не решаются. При том, что с ними элементарно справится
планировщик типовой RTOS. - fk0(11.06.2020 20:45)
- Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же
самое, что конечные автоматы им. Шалыто, switch-технология. Удобней
представлять в виде big loop всё-таки. Идея в том, что какой-то
"протопоток", "автомат", отдал управление обратно циклу и он
побежал вызывать остальные "протопотоки" или автоматы... fk0(4542 знак., 11.06.2020 19:54, ссылка, ссылка)
- Ну и зачем городить целую ОС, если я хочу самостоятельно разрулить
данную ситуацию? - BlackMorda(12.06.2020 08:20)
- Механизм доступа к общему ресурсу подразумевает, что кто-то иногда
его не будет получать и будет переходить в состояние ожидания, не
мешая работать остальным. Тут и возникает ОС, или ее эквивалент. - AlexBi(11.06.2020 16:48)
- Вы пошатнули мою веру в IAR. Как жить дальше? ;-) BlackMorda(93 знак., 11.06.2020 12:55)
- Говорить о семафорах или мьютексах без операционки -- бессмысленно.
Потому как их применение подразумевает побудку процессов ожидающих
данного семафора или мьютекса. И передачу управления другим
потокам/задачам при занятости ресурса (yield). Что нельзя сделать
без взаимодействия с ОС. Без ОС возможен только спинлок. - fk0(11.06.2020 11:30)
- IAR C/C++ Development Guide. Compiling and Linking for
STMicroelectronics’ STM8 Microcontroller Family BlackMorda(555 знак., 11.06.2020 11:19, ссылка)
- планировщик пишите с самым высоким приоритетом, и мутексы не понадобятся! - Aleksey_75(09.06.2020 23:00)
- mutex - это примитив операционной системы, а не рантайма, что вы
несете. Нужны мютексы - берете RTOS, там они и будут - lloyd(09.06.2020 17:50)
- Ему, похоже, просто атомарная переменная нужна. "А разговоров-то
было" - LightElf(09.06.2020 23:20)
- Мне нужно не изобретать велосипед. Судя по всему прийдется. BlackMorda(55 знак., 10.06.2020 10:31)
- Ты с терминологией разберись сначала (что есть мутекс, что семафор, а что - критическая секция) и хотя бы процессор укажи. Или не выеживайся и просто запрети прерывания. - LightElf(10.06.2020 12:30)
- Да ладно, проблему нашел. У меня семафор занятости SPI для работы с
двумя узлами, все проверено и работает. Не волшебную таблетку
искать нужно, а головой думать и ручками писать. VLLV(608 знак., 10.06.2020 11:11)
- Это не семафор. - BlackMorda(11.06.2020 11:26)
- Мне нужно не изобретать велосипед. Судя по всему прийдется. BlackMorda(55 знак., 10.06.2020 10:31)
- Ну да в 2010 году мютексы делались на 8-ми битниках, а теперь нужно RTOS? BlackMorda(57 знак., 09.06.2020 23:02, ссылка)
- Ему, похоже, просто атомарная переменная нужна. "А разговоров-то
было" - LightElf(09.06.2020 23:20)
- Если уж "изобретаем многозадачку", то изобрести семафор в виде
простого флага -- это вообще ерунда. SciFi(125 знак., 09.06.2020 16:42)
- В типичной ОС с семафором связан список ожидания, в который
становятся процессы ожидающие срабатывания данного семафора. И
будится один из процессов, первый в очереди. А у тебя -- spinlock,
совсем другая история. И да, там бы с атомарностью что-то
придумать: обычно достаточно примитива test and set (атомарного
инкремента, compare and swap...) Без атомарности не взлетит, т.к.
условие "!busy" может сработать сразу в двух потоках одновременно и
будет глюкодром. Нужна атомарная fk0(871 знак., 10.06.2020 10:47)
- достаточно запретить прерывания на время обращения к переменной. В
ИАРе для этого есть куча архитектурно-независимых интринсиков. - LightElf(11.06.2020 13:02)
- +1. Работало еще на 8080. - VLLV(11.06.2020 13:42)
- Что-то ARM объявил LDREX/STREX внезапно :) как: Chum_A(340 знак., 10.06.2020 13:55, ссылка, ссылка)
- Компилятор оказался умнее погромиздов. Погромизды сказали "это не баг, а фича" и нечего тут. - LightElf(10.06.2020 14:35)
- достаточно запретить прерывания на время обращения к переменной. В
ИАРе для этого есть куча архитектурно-независимых интринсиков. - LightElf(11.06.2020 13:02)
- Такой велосипед не поедет. BlackMorda(68 знак., 09.06.2020 22:56)
- Ждать в прерывании НЕЛЬЗЯ. По определению. В него нужно быстро
войти, быстро что-то сделать и быстро свалить. Про энтропию даже не
начинайте. - Xитpый Kитaeц(11.06.2020 09:58)
- А проверить в прерывании на не занятось ресурса как? - BlackMorda(11.06.2020 11:23)
- Если прерывание не может прерываться -- достаточно
переменной-флага. Если может -- нужна атомарная переменная с
функционалом test-and-set. - fk0(11.06.2020 11:28)
- "атомарная переменная с функционалом test-and-set." - это не мютекс? - BlackMorda(11.06.2020 15:13)
- Если прерывание не может прерываться -- достаточно
переменной-флага. Если может -- нужна атомарная переменная с
функционалом test-and-set. - fk0(11.06.2020 11:28)
- А проверить в прерывании на не занятось ресурса как? - BlackMorda(11.06.2020 11:23)
- Ждать можно и не в прерывании. Samx(95 знак., 10.06.2020 01:26)
- Заводить еще переменную которая будет опрашиватся в основном цикле? Энтропия вырастет. - BlackMorda(10.06.2020 10:39)
- Использовать мутексы в прерывании - весьма богатая идея. Сами придумали? - LightElf(09.06.2020 23:06)
- Не знаю, как у вас, а у меня всё работает. Main loop, protothreads, вот это всё. Прерывания там, где без них никак. Переключалка задач не нужна. - SciFi(09.06.2020 23:00)
- Ждать в прерывании НЕЛЬЗЯ. По определению. В него нужно быстро
войти, быстро что-то сделать и быстро свалить. Про энтропию даже не
начинайте. - Xитpый Kитaeц(11.06.2020 09:58)
- В типичной ОС с семафором связан список ожидания, в который
становятся процессы ожидающие срабатывания данного семафора. И
будится один из процессов, первый в очереди. А у тебя -- spinlock,
совсем другая история. И да, там бы с атомарностью что-то
придумать: обычно достаточно примитива test and set (атомарного
инкремента, compare and swap...) Без атомарности не взлетит, т.к.
условие "!busy" может сработать сразу в двух потоках одновременно и
будет глюкодром. Нужна атомарная fk0(871 знак., 10.06.2020 10:47)
- Вопрос чутка некорректный и вот почему. "Mutex" - понимается как
mutual exlusion вообще, в целом. Многие без достаточных на то
оснований полагают что Mutex это всенепременно объект "операционной
системы" и отсюда делается дальнейший вывод что гарантированно
нужна операционная система. Но это не так. Mutex это общее понятие,
никакой гарантии семантики или гарантированного интерфейса у этого
термина нет. В Microsoft операционке в API для межпроцессной
синхронизации RxTx(1490 знак., 11.06.2020 18:08)