Если вы хотите, чтобы источник данных всегда был на безопасной стороне параллелизма, у вас должен быть хотя бы один указатель, который всегда безопасен для его использования.
Таким образом, объект Observer должен иметь время жизни, которое не заканчивается до срока службы источника данных.
Это можно сделать, только добавив Наблюдателей, но никогда не удаляя их.
Вы можете заставить каждого наблюдателя не выполнять саму базовую реализацию, а поручить ему задачу ObserverImpl.
Вы блокируете доступ к этому объекту. Это не страшно, это просто означает, что отписчик GUI будет на некоторое время заблокирован, если наблюдатель занят, используя объект ObserverImpl. Если бы возникла проблема с отзывчивостью GUI, вы можете использовать какой-то параллельный механизм очереди заданий с заданием отмены подписки. (как PostMessage в Windows)
Когда вы отписываетесь, вы просто заменяете базовую реализацию фиктивной реализацией. Опять эта операция должна захватить блокировку. Это действительно привело бы к некоторому ожиданию источника данных, но, поскольку это всего лишь [блокировка - замена указателя - разблокировка], можно сказать, что этого достаточно для приложений реального времени.
Если вы хотите избежать укладки объектов Observer, которые содержат только фиктивный объект, вам нужно провести какую-то бухгалтерию, но это может сводиться к чему-то тривиальному, например, к объекту, содержащему указатель на нужный объект Observer из списка.
Оптимизация:
Если вы также поддерживаете реализации (настоящая + пустышка) до тех пор, пока сам Observer, вы можете сделать это без фактической блокировки и использовать что-то вроде InterlockedExchangePointer для обмена указателями.
В худшем случае: делегирование вызова происходит, когда указатель поменялся местами -> ничего страшного, все объекты остаются в живых, и делегирование может продолжаться. Следующий делегирующий вызов будет к новому объекту реализации. (Без каких-либо новых свопов, конечно)