Multi-threaded p/invoke

[Nicholas Paldino [.NET/C# MVP]]

Duncan,

Are you attributing the actual function delcaration with MethodImpl? If
so, then this is probably a bad idea, since it will lock on the type, and if
you have multiple method definitions on the same type, they will all lock on
the same thing (when it probably isn't required).

Are you sure that your library functions are not re-entrant? Are you
sure you have to do this?

If so, then what you should do is create an object (new object()) for
each function that you declare. Declare them as private, and then write
static wrappers around them. In the static wrapper, lock on the object that
corresponds to the method that you are calling through the P/Invoke layer.

Hope this helps.

 

[Nicholas Paldino [.NET/C# MVP]]

Duncan,

If the bottleneck will be on one particular method, then how is it the
synchronization of the calls to the DLL functions which is causing the
bottleneck? Based on what you said, it would seem this is not the case, and
that in fact, something else is amiss.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

Thanks for the quick response. I am only assuming that they are not
re-entrant because I was getting exceptions being thrown once I have moved
into mutli-threaded processesing that weren't there in the single threaded
versions: "Object not set to an instance of an object"; I am still in the
process of figuring out why this is. I am thinking maybe its my interop
complaining not the dll - but if I must declare pinvokes as static extern,
how can I avoid it?

I can see how your solution benefits me in that I lock on a single method
rather than the type that owns it however I am working with an encoding
dll
that will bottleneck on one particualar method so the improvement will not
be that marked.


in
message news:[email protected]...

Duncan,

Are you attributing the actual function delcaration with MethodImpl? If
so, then this is probably a bad idea, since it will lock on the type, and if
you have multiple method definitions on the same type, they will all lock on
the same thing (when it probably isn't required).

Are you sure that your library functions are not re-entrant? Are you
sure you have to do this?

If so, then what you should do is create an object (new object()) for
each function that you declare. Declare them as private, and then write
static wrappers around them. In the static wrapper, lock on the object that
corresponds to the method that you are calling through the P/Invoke
layer.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

message

Hi all,

Does anyone know of a way to achieve multi-theaded platform invokes? I
have
been taking quite a performance hit using the syncronised attribute:
[MethodImpl(MethodImplOptions.Synchronized)].

Cheers

 

[Duncan Mole]

Hi all,

Does anyone know of a way to achieve multi-theaded platform invokes? I have
been taking quite a performance hit using the syncronised attribute:
[MethodImpl(MethodImplOptions.Synchronized)].

Cheers

 

[Duncan Mole]

Hi Nicholas,

Thanks for the quick response. I am only assuming that they are not
re-entrant because I was getting exceptions being thrown once I have moved
into mutli-threaded processesing that weren't there in the single threaded
versions: "Object not set to an instance of an object"; I am still in the
process of figuring out why this is. I am thinking maybe its my interop
complaining not the dll - but if I must declare pinvokes as static extern,
how can I avoid it?

I can see how your solution benefits me in that I lock on a single method
rather than the type that owns it however I am working with an encoding dll
that will bottleneck on one particualar method so the improvement will not
be that marked.

Duncan,

Are you attributing the actual function delcaration with MethodImpl? If
so, then this is probably a bad idea, since it will lock on the type, and if
you have multiple method definitions on the same type, they will all lock on
the same thing (when it probably isn't required).

Are you sure that your library functions are not re-entrant? Are you
sure you have to do this?

If so, then what you should do is create an object (new object()) for
each function that you declare. Declare them as private, and then write
static wrappers around them. In the static wrapper, lock on the object that
corresponds to the method that you are calling through the P/Invoke layer.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi all,

Does anyone know of a way to achieve multi-theaded platform invokes? I
have
been taking quite a performance hit using the syncronised attribute:
[MethodImpl(MethodImplOptions.Synchronized)].

Cheers

 

[Duncan Mole]

Yeah, thats what I was *slowly* figuring. Can you see a problem with the
following

public static uint EncodeChunk(uint hbeStream, byte[] buffer, int index,
uint nBytes, byte[] pOutput, ref uint pdwOutput)

{

uint res = 0;

GCHandle handle = GCHandle.Alloc(buffer, GCHandleType.Pinned);

try

{

IntPtr ptr = (IntPtr)(handle.AddrOfPinnedObject().ToInt32()+index);

res = beEncodeChunk(hbeStream, nBytes/2/*Samples*/, ptr, pOutput, ref
pdwOutput);

}

catch (Exception e)

{

MessageBox.Show(e.Message);

}

finally

{

handle.Free();

}

return res;

}

Duncan,

If the bottleneck will be on one particular method, then how is it the
synchronization of the calls to the DLL functions which is causing the
bottleneck? Based on what you said, it would seem this is not the case, and
that in fact, something else is amiss.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

Thanks for the quick response. I am only assuming that they are not
re-entrant because I was getting exceptions being thrown once I have moved
into mutli-threaded processesing that weren't there in the single threaded
versions: "Object not set to an instance of an object"; I am still in the
process of figuring out why this is. I am thinking maybe its my interop
complaining not the dll - but if I must declare pinvokes as static extern,
how can I avoid it?

I can see how your solution benefits me in that I lock on a single method
rather than the type that owns it however I am working with an encoding
dll
that will bottleneck on one particualar method so the improvement will not
be that marked.


in
message news:[email protected]...

Duncan,

Are you attributing the actual function delcaration with

MethodImpl?
If

so, then this is probably a bad idea, since it will lock on the type,

and
if

you have multiple method definitions on the same type, they will all

lock
on

the same thing (when it probably isn't required).

Are you sure that your library functions are not re-entrant? Are you
sure you have to do this?

If so, then what you should do is create an object (new object()) for
each function that you declare. Declare them as private, and then write
static wrappers around them. In the static wrapper, lock on the object that
corresponds to the method that you are calling through the P/Invoke
layer.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

message
Hi all,

Does anyone know of a way to achieve multi-theaded platform invokes? I
have
been taking quite a performance hit using the syncronised attribute:
[MethodImpl(MethodImplOptions.Synchronized)].

Cheers

 

[Nicholas Paldino [.NET/C# MVP]]

Duncan,

Why are you pinning the address of the array? There isn't much reason
to do that, the P/Invoke layer will handle all of that for you (unless the
array is being held by the function somewhere else and operated on outside
of the call).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Yeah, thats what I was *slowly* figuring. Can you see a problem with the
following

public static uint EncodeChunk(uint hbeStream, byte[] buffer, int index,
uint nBytes, byte[] pOutput, ref uint pdwOutput)

{

uint res = 0;

GCHandle handle = GCHandle.Alloc(buffer, GCHandleType.Pinned);

try

{

IntPtr ptr = (IntPtr)(handle.AddrOfPinnedObject().ToInt32()+index);

res = beEncodeChunk(hbeStream, nBytes/2/*Samples*/, ptr, pOutput, ref
pdwOutput);

}

catch (Exception e)

{

MessageBox.Show(e.Message);

}

finally

{

handle.Free();

}

return res;

}




in
message news:%[email protected]...

Duncan,

If the bottleneck will be on one particular method, then how is it
the
synchronization of the calls to the DLL functions which is causing the
bottleneck? Based on what you said, it would seem this is not the case, and
that in fact, something else is amiss.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

message

Hi Nicholas,

Thanks for the quick response. I am only assuming that they are not
re-entrant because I was getting exceptions being thrown once I have moved
into mutli-threaded processesing that weren't there in the single threaded
versions: "Object not set to an instance of an object"; I am still in the
process of figuring out why this is. I am thinking maybe its my interop
complaining not the dll - but if I must declare pinvokes as static extern,
how can I avoid it?

I can see how your solution benefits me in that I lock on a single method
rather than the type that owns it however I am working with an encoding
dll
that will bottleneck on one particualar method so the improvement will not
be that marked.


"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote
in
message Duncan,

Are you attributing the actual function delcaration with MethodImpl?
If
so, then this is probably a bad idea, since it will lock on the type, and
if
you have multiple method definitions on the same type, they will all lock
on
the same thing (when it probably isn't required).

Are you sure that your library functions are not re-entrant? Are you
sure you have to do this?

If so, then what you should do is create an object (new object()) for
each function that you declare. Declare them as private, and then write
static wrappers around them. In the static wrapper, lock on the
object
that
corresponds to the method that you are calling through the P/Invoke
layer.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

message
Hi all,

Does anyone know of a way to achieve multi-theaded platform invokes? I
have
been taking quite a performance hit using the syncronised attribute:
[MethodImpl(MethodImplOptions.Synchronized)].

Cheers