Приведет ли удаление объекта, во время исполнение его методов(с обращением к внутренним полям объекта) к непредсказуемому/нестабильному поведению программы?

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

2) Если да, то какой из способов защиты будет менее затратный по времени: Mutex или Умный указатель?

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

Я делал без всяких защит так: потоки работают с элементами, и, по окончании данных признак ставят. А каждые 5 минут чищу. Если что речь о TCP соединениях. Т.е. возобновиться они не могут. А обработчик соединений у меня в режиме пулинга и с чистильщиком не пересекается.

какой из способов защиты будет менее затратный по времени: Mutex или Умный указатель?

std::unique_ptr не потокобезопасный

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

Ну, например, в дотнете до 4-ого фреймворка GC был полностью блокирующий, то есть все потоки останавливались и GC очищал память. То есть начальном этапе наверное не стоит прямо таки заморачиваться - это раз. Во-вторых, всему коду не угодишь, разные подходы будут более эффективны в тех или иных случаях.

FIFO запретили?

1) Приведет ли удаление объекта, во время исполнение его методов(с обращением к внутренним полям объекта) к непредсказуемому/нестабильному поведению программы?

В общем случае - да

2) Если да, то какой из способов защиты будет менее затратный по времени: Mutex или Умный указатель? (какие еще могут быть варианты для c++11?)

std::shared_ptr.

Удалять объекты после исполнения методов в тех же потоках (ты эту архитектуру под грибами придумал?) религия не позволяет?

Ответы:

1. Да.

2. Умные указатели — это совсем о другом, а за массивы mutex-ов надо стерелизовать. Запили два контейнера: пока первый набивается свежими данными, второй обрабатывается; обработанный контейнер прибивается за один раз и указатели на них меняются местами.

А нельзя сделать так, чтобы метод не пользовался «внутренними полями объекта»? А то выглядит как будто ты сам аккуратно зафиксировал ногу и стреляешь в нее многопоточно из нескольких ружей)

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

1 поток(вернее их с десяток, но можно представить как один) отвечает за исполнения методов, а второй за изъятия их из вектора и последующие удаление(GC в общем)

Руки не из того места. Обработчик изымает событие из очереди входящих, вызывает метод и по его завершении удаляет событие. Как вариант, если удаление события почему-то длительная операция (сброс кэшей какой-ибудь например), организуй вторую очередь - очередь обработанных событий, и в обработчике не удаляй событие, а перекладывай его во вторую очередь, откуда их будут забирать десяток GC.

1) Да. Разве это не очевидно? 2) С shared_ptr код будет мягким и шелковистым. С мутексами ты его сам через месяц не разберёшь.

если уж берётесь учить детей плохому...

... то нелишним будет заметить, что это касается только c++11 std::shared_ptr, но не boost::shared_ptr. И никакие умные указатели не будут синхронизировать доступ к объектам.

это касается только c++11 std::shared_ptr, но не boost::shared_ptr

Почему?