Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Interop / October 2004

Tip: Looking for answers? Try searching our database.

PInvoke threading issue

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Brett Robichaud - 01 Oct 2004 20:05 GMT
I have created a simple background thread to make one pinvoke call into a
DLL I've created.  My Winforms app spawns the thread in the form load event
then go about it's business.  The problem is that my form appears to be
blocked while the background thread is running.

I am very familir with threads in unmanaged code but am just getting into
them in C#.  Are there issues I need to be aware of with regards to
threading a simple pinvoke call?

As an experiment I replaced my pinvoke call with a simple
Thread.Sleep(5000).  This gave me the result I expected, my UI was
responsive during the entire 5 seconds the thread was waiting.  Changing the
wait back into a pinvoke call caused my UI to not redraw until the pinvoke
call completed.

Any idea what's up?

-Brett-
Willy Denoyette [MVP] - 01 Oct 2004 20:14 GMT
What exactly are you doing in your PInvoke'd function? Looks like you are
blocking the message pump or preventing the message loop to call the MSG
handler because you are "monopolizing" the CPU.

Willy.

>I have created a simple background thread to make one pinvoke call into a
> DLL I've created.  My Winforms app spawns the thread in the form load
[quoted text clipped - 16 lines]
>
> -Brett-
Brett Robichaud - 01 Oct 2004 21:28 GMT
My code is wrapping a 3rd party library so I honestly don't know fully what
they are doing.  So it is possible that something down in that unmanaged
code could cause the main ui thread to block?  I guess I was just looking to
see if there were some fundamental issues with using pinvoke in a worker
thread that I needed to be aware of.  Sounds like that isn't the case.

-Brett-

> What exactly are you doing in your PInvoke'd function? Looks like you are
> blocking the message pump or preventing the message loop to call the MSG
[quoted text clipped - 22 lines]
> >
> > -Brett-
"Peter Huang" - 05 Oct 2004 06:53 GMT
Hi Brett,

It is strange, can you post the code the main UI thread doing after you
have created  the working thread.
Did the main UI threading doing something to wait for the working thread?
Is there any race condition between the main UI thread and the working
thread which will do the P/Invoke?

Best regards,

Peter Huang
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Brett Robichaud - 05 Oct 2004 18:35 GMT
No the main UI thread is not waiting on the worker thread in any way.  I
actually experiemented with join and other techniques for waiting on the
thread and it acted exactly the same.  This really brought me to the
conclusion that the worker thread is somehow blocking the main ui thread.

The code I'm calling in the worker thread is a code protection library by
Aladdin.  They have a technique where they encrypt a DLL using a hardware
dongle (hasp).  It is a very slow process to unencrypt it so I decided to
thread the pinvoke call.  I have no idea what they are doing down there but
it definitely does not act like a good threaded citizen.

-Brett-

> Hi Brett,
>
[quoted text clipped - 11 lines]
> Get Secure! - www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no rights.
"Peter Huang" - 06 Oct 2004 04:35 GMT
Hi Brett,

So far it is hard to guess what had happen, I think there must be something
underlying race condition which will cause the blcok.
I think you would better contact MS PSS which will do further touble
shooting about your issue. e..g live debugging or dump analysis which is
beyond newsgroup support boundary.

Thank you for you understanding!

Best regards,

Peter Huang
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

"Peter Huang" - 06 Oct 2004 09:56 GMT
Hi,

One possibility is that if the third-party dll called a COM object which is
main threaded  that is to say we did not specified the thread model for the
COM Object. In this way, the COM object will be created and running on the
main thread, i.e. the main UI thread which may cause the main UI form
thread blocked. Usually the main thread is the first thread in the process.

So I think you may try to change your code as below.
<code snippet>
[STAThread]
static void Main()
{
               //run the winform in the second thread.
    Thread th = new Thread(new ThreadStart(ThreadProc));
    th.Start();

              //Run the P/Inovke code in the main thread, try to replace
the three code lines below
    TestCOMP.COMPClass tcc = new TestCOMP.COMPClass();
    tcc.SleepVB(1000);
}
public static void ThreadProc()
{
    Application.Run(new Form1());
}
</code snippet>

Best regards,

Peter Huang
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.