.NET垃圾收集，C ++ / CLI interior

.NET垃圾收集，C ++ / CLI interior_ptr和线程安全(.NET Garbage Collection, C++/CLI interior_ptr, and Thread Safety)

所以我理解使用fixed语句可以使用interior_ptr<typename>来完全使用结构数组，但是它不会修复堆上的数组，并让垃圾收集移动它。 这很好，因为我不想阻止垃圾收集器有效地工作。 但是，垃圾收集器在单独的线程上运行，并且当它处于活动状态时，所有其他线程在堆上的对象被压缩时停止。

假设我有以下代码：

interior_ptr<unsigned char> sourceBufferPtr = reinterpret_cast<interior_ptr<unsigned char>>(&sourceBuffer[0]) + sourceOffset;

代码应该像这样运行，例如：

&sourceBuffer[0]返回数组中第一项的地址：32。 sourceOffset ：8。 reinterpret_cast<interior_ptr<unsigned char>>(&sourceBuffer[0])将地址强制转换为interior_ptr<unsigned char> ，并将其添加到sourceOffset 。 sourceBufferPtr应该等于...... 40如果垃圾收集器没有移动阵列。 24如果垃圾收集器将数组移动到16之类的位置。 如果垃圾收集器在步骤3和4之间移动数组，则为40，因此在步骤3之后，阵列的位置将更新为16，但分配给sourceBufferPtr的结果仍为40。

我是否正确假设垃圾收集器可以在步骤3和4之间停止线程并可能为sourceBufferPtr分配错误的值或公共语言运行时以某种方式知道如何确保整个语句的原子/值是正确的？ 使用interior_ptr<typename> 可以安全地做什么？

So I understand that interior_ptr<typename> can be used to operate with arrays of structs exactly as in C♯ using the fixed statement, but it doesn't fix the array on the heap and lets garbage collection move it around. That's good as I don't want to impede the garbage collector from working effectively. However, the garbage collector runs on a separate thread, and when it is active all the other threads are stopped while the objects on the heap are compacted.

Supposed I had the following code:

interior_ptr<unsigned char> sourceBufferPtr = reinterpret_cast<interior_ptr<unsigned char>>(&sourceBuffer[0]) + sourceOffset;

The code should runs like this, for example:

&sourceBuffer[0] returns the address of the first item in the array: 32. sourceOffset: 8. reinterpret_cast<interior_ptr<unsigned char>>(&sourceBuffer[0]) casts the address to an interior_ptr<unsigned char>, which gets added to sourceOffset. sourceBufferPtr should be equal to… 40 if the garbage collector did not move the array. 24 if the garbage collector moved the array to a location like 16. of 40 if the garbage collector moved the array between steps 3 and 4, so the location of the array would be updated to 16 after step 3, but the result assigned to sourceBufferPtr would still be 40.

Am I correct to assume that the garbage collector could stop the thread between steps 3 and 4 and possibly assign the wrong value to sourceBufferPtr or does the Common Language Runtime somehow know how to ensure the entire statement is atomic/value is correct? What is safe to do with interior_ptr<typename>?

最满意答案

我是否正确假设垃圾收集器可以在步骤3和4之间停止线程并可能将错误的值分配给sourceBufferPtr？

是的，因为您的代码不正确。 通过在获得指向数组元素的无错指针后使用reinterpret_cast ，您将为GC引入一个机会窗口使指针无效。 您需要像这样不间断地使用interior_ptr：

interior_ptr<unsigned char> bufferPtr = &sourceBuffer[0]; interior_ptr<unsigned char> sourceBufferPtr = bufferPtr + sourceOffset;

在这个新代码中，只有interior_ptr。 即使是第二个任务右侧的临时文件也是interior_ptr。

Am I correct to assume that the garbage collector could stop the thread between steps 3 and 4 and possibly assign the wrong value to sourceBufferPtr?

Yes, because your code is incorrect. By using reinterpret_cast after having obtained an unmaanged pointer to the array element you are introducing a window of opportunity for the GC to invalidate the pointer. You need to use interior_ptr without interruption like this:

interior_ptr<unsigned char> bufferPtr = &sourceBuffer[0]; interior_ptr<unsigned char> sourceBufferPtr = bufferPtr + sourceOffset;

In this new code, there are only ever interior_ptr's. Even the temporary on the right-hand-side of the second assignment is an interior_ptr.