йцyкeн (29.11.2020 17:00, просмотров: 3605)
delete this - говнокод? Задача: основная программа порождает
объект, который по сути представляет собой отдельный процесс
(измерение). Внутри него живёт на прерываниях конечный автомат,
который со временем доходит до состояния end, и тогда объект нужно
прибить. Не хочется опрашивать состояние объекта из основной
программы, хочется, чтобы он сам застрелился. Чем чревато ? delete this
-
- Не проблема, если есть гарантия, что суицид будет таки вызван. - fk0(30.11.2020 01:14)
- Объект без хозяина - зло. Поэтому delete this - говнокод, да. lloyd(82 знак., 29.11.2020 17:13)
- malloc/free не умеет в прерывания жи, не? В смысле делает вид, что
умеет, пока не случится самый неподходящий момент. - SciFi(29.11.2020 17:02)
- Понятно, что если прерывание случается во время выполнения
malloc/free, и само вызывает malloc/free, ничем хорошим это не
кончится. Предположим, этот момент удалось обойти (placement new?).
Вопрос был, не может ли сама конструкция delete this выйти боком. - йцyкeн(29.11.2020 17:12)
- У меня была похожая ситуация с malloc/free - одновременный вызов в
разных процессах. Обходил через свои malloc/free с блокировкой
одновременного вызова с помощью мьютекса внутри. - AlexG(30.11.2020 04:53)
- Что значит в разных процессах? Я в вопросе не написал, но меня
никакой операционки нет, это типа многозадачность для бедных. В
винде, ЕМНИП, в разных процессах malloc/free вообще работают каждый
со своей heap, и синхронизация не нужна. Потоки одного процесса
пользуются общей памятью, но там синхронизация и так есть. Или я
ошибаюсь? - йцyкeн(30.11.2020 18:12)
- Вызов обработчика прерывания практически ничем не отличается от
переключения операционки на выполнение другого процесса. Проблемы
те-же. - AlexG(30.11.2020 20:53)
- Речь скорей о том, что есть много embedded RTOS в которых
опрометчиво положили болт на (не)совместимость с libc. Т.е. вроде
как ОС взяли, многозадачность сделали, а то, что libc о ней ни
ухом, ни рылом -- даже не задумались. Я писал об этом ранее много
раз -- причина, почему RTOS не нужна, если нет качественной libc
увязанной с ОС. Иначе программировать невозможно. Неизвестно где
искать проблемы. Потенциально в любой потоконебезопасной функции,
любой функции использующей fk0(158 знак., 30.11.2020 18:22)
- Ну мы же не про Си, а про плюсплюс. Там в STL сплошные new и
delete. И что, можно использовать std::vector без мутексов только в
одном потоке? - йцyкeн(30.11.2020 19:06)
- new -- это вызов operator new(sizeof(T)) и последующий вызов Т(...)
delete -- вызов ~T() и вызов operator delete(). Для массивов ещё
добавляется пробежка по всем элементам массива и вызов T() или ~T()
для каждого. Обычно функции operator new() и operator delete() --
этот тот же malloc() и free()... Так что в менеджменте памяти
ничего нового. Конечно нельзя вектор без мьютекса использовать
параллельно в разных потоках. Впрочем это касается любого класса
вообще. Любой fk0(123 знак., 30.11.2020 22:19)
- Я не про использование одного и того же вектора, а про ситуацию,
когда функция в одном потоке имеет локальную переменную типа
vector<double>, а функция в другом потоке - другую
переменную, и не обязательно vector, пусть это будет
map<string, int>. Я думаю, что new и delete потоков
работают с одним пулом памяти, и это требует синхронизации, и она в
"настоящих" операционках есть, а с RTOS для микроконтроллеров я
дела не имел. - йцyкeн(30.11.2020 23:33)
- >>> - SciFi(29.11.2020 17:14, ссылка)