caxapa.ru :: Понятно, что если прерывание случается во время выполнения malloc/free, и само вызывает malloc/free, ничем хорошим это не кончится. Предположим, этот момент удалось обойти (placement new?). Вопрос был, не может ли сама конструкция delete this выйти боком.

йцyкeн (29.11.2020 17:12, просмотров: 262) ответил SciFi на malloc/free не умеет в прерывания жи, не? В смысле делает вид, что умеет, пока не случится самый неподходящий момент.

Понятно, что если прерывание случается во время выполнения malloc/free, и само вызывает malloc/free, ничем хорошим это не кончится. Предположим, этот момент удалось обойти (placement new?). Вопрос был, не может ли сама конструкция delete this выйти боком.

Ответить

- У меня была похожая ситуация с 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)
      - Другие. Во-первых в прерываниях не будет выполняться произвольный код, библиотеки и т.п. Только код обработчика прерывания. Во-вторых и самое главное, в прерывании нельзя заблокироваться (на мьютексе, семафоре...) И наконец прерывание имеет гарантию, что его может вытеснить более высокоуровневое прерывание только, а не пользовательский код. fk0(709 знак., 30.11.2020 22:14)
    - Речь скорей о том, что есть много 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, ссылка)
  - Спасибо. Я так понял, что работать будет, но подводных камней много. Возможно, оно того не стОит. - йцyкeн(29.11.2020 18:32)

Средства и методы разработки