这会使对象成为线程安全的吗？
我有一个本机 Visual C++ COM 对象，我需要使其完全线程安全，以便能够在系统注册表中合法地将其标记为“自由线程”。具体来说，我需要确保不超过一个线程同时访问该对象的任何成员变量。
问题是我几乎可以肯定，任何理智的 COM 对象使用者都不会尝试同时从多个线程使用该对象。所以我希望解决方案尽可能简单，只要满足上述要求即可。
这就是我的想法。我添加互斥锁或临界区作为对象的成员变量。每个 COM 公开的方法都会在开始时获取互斥体/部分，并在返回控制之前释放。
我知道这个解决方案不提供细粒度的访问，这可能会减慢执行速度，但由于我认为同时访问不会真正发生，所以我不在乎这一点。
这个解决方案足够吗？有更简单的解决方案吗？
I have a native Visual C++ COM object and I need to make it completely thread-safe to be able to legally mark it as "free-threaded" in th system registry. Specifically I need to make sure that no more than one thread ever accesses any member variable of the object simultaneously.
The catch is I'm almost sure that no sane consumer of my COM object will ever try to simultaneously use the object from more than one thread. So I want the solution as simple as possible as long as it meets the requirement above.
Here's what I came up with. I add a mutex or critical section as a member variable of the object. Every COM-exposed method will acquire the mutex/section at the beginning and release before returning control.
I understand that this solution doesn't provide fine-grained access and this might slow execution down, but since I suppose simultaneous access will not really occur I don't care of this.
Will this solution suffice? Is there a simpler solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个解决方案应该可行，但我建议在关键部分使用互斥体，因为它们处理超时，这在死锁的情况下提供了一定程度的回退。您还需要非常小心，锁定互斥锁的函数不会调用已在同一线程中锁定相同互斥锁的另一个函数。这对于您的 COM 接口来说应该不是问题，只要您不在互斥体之上向接口添加额外的功能即可。如果 COM 包含回调，您可能会遇到问题。
This solution should work, but I'd recommend mutexes over critical sections as they handle time-outs, which provide some level of fall back in case of deadlock. You also want to be very careful that a function locking a mutex does not call another function that has already locked the same mutex in the same thread. This shouldn't be a problem for your COM interface, so long as you don't add extra functionality on top of your mutex to the interface. You could hit issues if the COM includes call backs.
如果您确定在实践中不会发生实际的并发访问，那么互斥整个执行并不是一个不合理的方法。
If you are certain that actual concurrent access is not going to happen in practice, then mutexing the entire execution is not an unreasonable approach.