[MS] If we can have std::atomic
Some time ago, we peeked inside the atomic shared_ptr to see how it worked. Can we apply these same principles to create an atomic com_ptr?
Recall that the atomic shared_ptr operates by using the bottom bit of the control block pointer as a lock flag, so that nobody can change the value while we're copying the pointer and incrementing the reference count. Can we do this with a com_ptr?
We could use the same trick of using the bottom bit of the raw COM pointer as a lock flag. This is acceptable because COM pointers must be pointer-aligned (since they point to a vtable), so we know that the bottom bit of a valid COM pointer is clear. However, we run into trouble when trying to increment the reference count: The call to IUnknown:: happens while the lock is held, but the AddRef is a call out to external code, and we don't know what it's going to do. We know what it's supposed to do (namely, increment the reference count), but it may take a circuitous route to get there, including passing through aggregated controlling unknowns, tear-off stubs, tear-offs of aggregated objects, weak outer pointers, and other fanciful characters.
We know that holding a lock while calling out to external code is a source of deadlocks, so holding a lock while calling out to a mystery implementation of IUnknown:: is probably not a good idea.
Sorry.
Post Updated on April 25, 2025 at 03:00PM
Thanks for reading
from devamazonaws.blogspot.com
Comments
Post a Comment