How to detect if an object has been pinned

[msedi]

I have a method that returns either managed or unmanaged memory

ReadOnlySpan<T> GetData<T>()

The method lives in various providers where one can return managed memory and another can return unmanaged memory. The problem is that is that I don't know if the value is pinned and I can get a pointer to the underlying data. As said above the data can be managed but could already have been pinned by GC.AllocateArray() pinned=true or could simply come from a regular GC.AllocateArray because it is an implementation detail and I don't want to force the pinned allocation since its only required in special interop scenarios and, if not done correctly could lead to very random and untraceable errors.

On the other side there is unmanaged array where I don't need to do anything.

Since the ReadOnlySpan<T> is handed over in a async P/Invoke call I want to check in advance if the memory has been pinned already. If there no additional cost I could do it again with fixed but the problem is that the method returns immediately and is executed by some other means of thread on an external device (GPU).

So just holding the fix inside the method is not enough. I need to fixed it over the whole lifetime of the execution. But since fixing the memory is in the hand of the implementor that calls my library I need to prevent errors by checking if the memory is indeed fixed.

Any ideas?

[stephentoub]

You don't. If you need it to be pinned, you need to pin it. The alternative is you document that it must be pinned and leave it up to the caller to ensure it, being very clear about how dangerous the API is, or force the user to pin if necessary by accepting a pointer instead of a managed reference. You could also accept a Memory<T>, which supports carrying a bit in it that let's the user say that it was created with a pinned object, and then when you call Memory.Pin, it won't create another GCHandle. Such instances can be created with MemoryMarshal.CreateFromPinnedArray.

[msedi]

@stephentoub. Thanks for the answer. That was my fear ;-) Currently the return type is an array, which I had to copy because returning a direct reference allows the user to modify the data. With the advent of ReadOnlySpan<T> I could introduce readonly returns without the need to copy the data. This wouldn't break interfaces because the ReadOnlySpan<T> can be used the same way as the old array implementation.

Introducing Memory<T> would break the interface and since our codebase is too large this is a no go at the moment. Also Memory can not be created from unmanaged memory (which I have) and would require an UnmanagedMemoryManager which does not exist. Additionally my memory is build in chunk (thousands of small chunks, ~80000 chunks where each chunk is around 64MB in total I sometimes have to deal with 20TB memory) which would require me to set up a MemoryManager for each chunk.

[stephentoub]

This wouldn't break interfaces because the ReadOnlySpan can be used the same way as the old array implementation.

Changing a return type from an array to a span is both a source and binary breaking change. Some existing uses might successfully recompile, but others definitely wouldn't, and regardless would break existing compiled usage. If you're breaking the interface for that, why not go further?

unmanaged memory (which I have)

If you already support pointers, then why can't your callers just call that if they've already pinned?

Also Memory can not be created from unmanaged memory (which I have) and would require an UnmanagedMemoryManager which does not exist.

We don't ship such a memory manager built-in, but you can certainly write one yourself or use our someone else has written.

That was my fear ;-)

Determining whether something is pinned would be incredibly expensive; in the case of fixed, it's not even until the GC scans stacks that it's aware of the pinning pointer. On top of that, any such mechanism for asking whether an object is pinned could be instantly wrong the moment after you query it and couldn't be relied on for safety, anyway.