Multi-threaded p/invoke

[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(Meth odImplOptions.S ynchronized)].

Cheers
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

[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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in message
news:Yx******** *********@newsf e3-gui.ntli.net...

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(Meth odImplOptions.S ynchronized)].

Cheers
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

[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.
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote in
message news:uK******** ******@TK2MSFTN GP12.phx.gbl...

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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in message
news:Yx******** *********@newsf e3-gui.ntli.net...

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(Meth odImplOptions.S ynchronized)].

Cheers
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

[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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in message
news:rX******** ********@newsfe 3-gui.ntli.net...

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]" <mv*@spam.guard .caspershouse.c om> wrote
in
message news:uK******** ******@TK2MSFTN GP12.phx.gbl...

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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in
message
news:Yx******** *********@newsf e3-gui.ntli.net...

> 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(Meth odImplOptions.S ynchronized)].
>
> Cheers
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
>
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

[Duncan Mole]

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

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

{

uint res = 0;

GCHandle handle = GCHandle.Alloc( buffer, GCHandleType.Pi nned);

try

{

IntPtr ptr = (IntPtr)(handle .AddrOfPinnedOb ject().ToInt32( )+index);

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

}

catch (Exception e)

{

MessageBox.Show (e.Message);

}

finally

{

handle.Free();

}

return res;

}


"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote in
message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in message
news:rX******** ********@newsfe 3-gui.ntli.net...

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]" <mv*@spam.guard .caspershouse.c om> wrote
in
message news:uK******** ******@TK2MSFTN GP12.phx.gbl...

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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in
message
news:Yx******** *********@newsf e3-gui.ntli.net...
> 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(Meth odImplOptions.S ynchronized)].
>
> Cheers
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
>
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004

[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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in message
news:zK******** *********@newsf e3-gui.ntli.net...

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

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

{

uint res = 0;

GCHandle handle = GCHandle.Alloc( buffer, GCHandleType.Pi nned);

try

{

IntPtr ptr = (IntPtr)(handle .AddrOfPinnedOb ject().ToInt32( )+index);

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

}

catch (Exception e)

{

MessageBox.Show (e.Message);

}

finally

{

handle.Free();

}

return res;

}


"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote
in
message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

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]
- mv*@spam.guard. caspershouse.co m

"Duncan Mole" <du************ **************@ ntlworld.com> wrote in
message
news:rX******** ********@newsfe 3-gui.ntli.net...

> 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]" <mv*@spam.guard .caspershouse.c om>
> wrote
> in
> message news:uK******** ******@TK2MSFTN GP12.phx.gbl...
>> 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]
>> - mv*@spam.guard. caspershouse.co m
>>
>> "Duncan Mole" <du************ **************@ ntlworld.com> wrote in
>> message
>> news:Yx******** *********@newsf e3-gui.ntli.net...
>> > 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(Meth odImplOptions.S ynchronized)].
>> >
>> > Cheers
>> >
>> >
>> > ---
>> > Outgoing mail is certified Virus Free.
>> > Checked by AVG anti-virus system (http://www.grisoft.com).
>> > Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
>> >
>> >
>>
>>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
>
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004