|
|
1
7
Unsubscribes()应该是同步的,这样它就不会返回,直到Observer被保证不再在Subject的列表中。这是唯一安全的方法。
由于时间似乎不是问题,在通知每个观察者之间获取并释放互斥体。你不能像现在这样使用for_each,你必须检查迭代器以确保它仍然有效。
|
|
|
2
3
关于这很难“正确”的例子,请参阅 Boost.Signals adopted -但尚未分发 Boost.Signals2 |
|
3
1
“理想”的解决方案将涉及使用
通过这种结构,我们创建了一个循环图,但要明智地使用
注意:此解决方案完全无法解释
|
|
|
4
1
这并不太繁重。 |
|
|
5
1
|
|
|
6
1
重新思考编辑 好的,现在我想我明白你的问题了。我认为解决你问题的最好办法是做以下事情: 鉴于取消订阅操作将阻塞互斥体以重置有效标志(并且该特定观察者将不再在您的线程中使用),该代码是线程安全的,客户端可以在取消订阅返回后立即删除任何观察者。 |
|
|
7
1
这样的东西令人满意吗?尽管如此,在收到通知时取消订阅观察者仍然是不安全的,因为你需要一个像你提到的那样的界面(据我所知)。
(客户IMO的一个糟糕的设计决定……) 您可以将通知线程的线程id添加到数据结构中。在Unsubscribe函数中,您可以根据当前线程的id检查该线程id(大多数线程库都提供此功能,例如pthread_self)。如果它们相同,则无需等待条件变量即可继续。 注意:如果客户端负责删除观察者,这意味着您会遇到这样的情况,即在Notify回调中,您将取消订阅并删除了观察者,但仍在使用该指针执行某些操作。客户端必须意识到这一点,并且只能在Notify()结束时删除它。 |
|
|
8
0
|
|
|
9
0
|