对任何 IStream实现来说，对COM的正式要求是，它应该是线程安全的，就可以IStream跨线程通过同一接口指针并发地访问方法而言。
我不是在谈论数据完整性（通常，无论如何，读/写/搜索都应该与锁同步）。问题是需要使用COM编组器将IStream对象从其他COM单元传递到线程。
这比我问一个更普遍的问题，IStream通过返回的CreateStreamOnHGlobal，请参阅有更多的技术细节。我只是想更好地理解这些东西。
编辑，我已经在MSDN上找到此信息：
线程安全。从Windows 8开始，由SHCreateMemStream创建的流是线程安全的。在较早的系统上，该流不是线程安全的。CreateStreamOnHGlobal创建的流是线程安全的。
现在我相信，由IStream返回的对象CreateStreamOnHGlobal是线程安全的，但是没有要求其他IStream实现遵循此要求。
不，不是。对另一个问题的公认答案是完全错误的。汉斯·帕桑特的答案是正确的。您应该删除此问题，因为它有一个错误的假设，即CreateStreamOnHGlobal返回线程安全的IStream。没有。然后，您问其他IStream实现是否如此。不是。
通常，在计算机编程中，尤其是在COM中，对象具有保证对象给予和不给予对象的保证。如果您使用符合其保证的对象，那么它将一直有效（除非存在错误）。如果您超出了保证范围，它可能在大多数时间仍然有效，但是不再保证。
通常，在COM中，线程安全保证由标准线程模型之一提供。
看到这里：http : //msdn.microsoft.com/en-us/library/ms809971.aspx
注意：线程模型属于对象而不是interface。一些支持的对象IStream可能是单线程的，其他的则可能是全线程安全的。这取决于实现接口的代码。因为接口只是一个规范，所以线程安全性不受它覆盖。
封送接口始终是无害的。如果线程的线程模型与对象的主线程兼容，则将获得完全相同的接口指针。如果它们不兼容，您将获得代理。但是，封送从来没有伤害，除非您知道对象是兼容的，否则应始终封送。
但是，实施者始终可以给予其他保证。
对于CoMarshalInterthreadInterfaceInStream，在文档中会告诉您IStream可以使用返回的接口将其用于在目标线程处进行编组CoUnmarshalInterfaceAndReleaseStream。
也就是说，您得到了额外的保证。因此，您可以依靠该工作。
但这IStream在任何时候都不适用于任何其他实例。
因此，您应该始终将其编组。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句