Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is passing a float[] as ref float to unmanaged code a good idea?

I would like to pass a float[] to a C method. The C signature looks like:

EXTERN int process_raw(float *inBuffer, float *outBuffer);

in C# the signature is:

public static extern int process_raw(ref float inBuffer, ref float outBuffer);

will it be problematic to pass arrays with a ref to the first member:

process_raw(ref someArray[0], ref anotherArray[0])

thanks!

EDIT: Of course its important to know what the C code does with the floats: It will treat them as arrays and will read values from inBuffer and will write values to outBuffer. As discussed below, the question is whether the whole memory will be pinned during the PInvoke call?

EDIT 2: Another comment. I chose the ref float on purpose because i also wanted to do things like:

fixed(byte* outBuff = buffer)
{
    Process(ticks, ref aFloat, ref ((float*)outBuff)[0]);
}

In this case it should be no problem, because the pointer is fixed anyways, but the question for normal array as above remains.

like image 962
thalm Avatar asked Apr 18 '12 20:04

thalm


2 Answers

There is no auto-pin involved in p/Invoke. P/Invoke is strictly performed via marshalling! (without unsafe code) To marshal means to allocate (unmanaged) memory and copy. Under covers there is probably a pin for the duration of the copy, but not for the duration of the native function call.

If you need to pass an array of 64 floats in and out of a native function you have two choices:

  1. Marshall it through.
  2. Use unsafe code to pin and pass the managed memory directly.

Here is the marshalled method:

[DllImport(...)]
private extern static int process_raw([In] float[] inBuffer, [Out] float[] outBuffer);

Note that I added the [In] and [Out] attributes as they tell the Marshaller (In) not to copy on the way out and (Out) not to copy on the way in. It's a good idea to always consider those attributes when writing a p/invoke declaration.

Here is the unsafe method:

[DllImport(...)]
private extern static unsafe int process_raw(float * inBuffer, float * outbuffer);

public static unsafe int Process(float[] inBuffer, float[] outBuffer)
{
    // validate for null and Length < 64
    fixed (float * pin = inBuffer)
    fixed (float * pout = outBuffer)
        return process_raw(pin, pout);
}

Expanded Comment

It is my understanding that the Marshaller is able to "under certain circumstances" choose to pin the managed memory instead of allocating unmanaged memory and copying. The problem with that is: What circumstances?

I don't know the answer, but I have a suspicion: When the native DLL is certain system DLLs. That's only a guess.

What this means to you and I is quite simple: Always begin with the marshalled method. If you're having performance issues and the profiler tells you that the native call is consuming a significant portion of time, then you can try the unsafe method and profile it again. If there is no significant improvement, then you're only hope is to optimize the native call.

like image 153
Tergiver Avatar answered Nov 13 '22 18:11

Tergiver


It's a little ambiguous what you're trying to do here. The native code could be treating the float* as a pointer to a float or an array of float values.

If the native code thinks it's a pointer to a single float then your code is just fine. Having the float be a ref in managed and pointer in native will marshal correctly.

If the native code thinks it's an array of float values then you most likely have a problem. This will work in the corner case it treats it as an array of length 1. For any other length though you need to use an actual array in the managed signature

public static extern int process_raw(float[] inBuffer, float[] outBuffer);
like image 20
JaredPar Avatar answered Nov 13 '22 18:11

JaredPar