By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,670 Members | 1,526 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,670 IT Pros & Developers. It's quick & easy.

Thread.Susspend

P: n/a
Hi,
I create a thread which load DLL and have DLL function call,this Dll
function takes a lot of time.
My Question is , if I request Thread.Susspend(), and the thread is inside
the Dll function (Dll function not finished yet, and thread function wait for
this function (DLL)call to compleate), what will happen ? is this will
susspend also the Dll function execution ? or will delay the susspend untill
this function returned ?

Thx
Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
> this function (DLL)call to compleate), what will happen ? is this will
susspend also the Dll function execution ? or will delay the susspend
untill
this function returned ?

It will stop the thread, wether it's running your code, DLL code, or
waiting for return information.

You have to resume the thread for work to continue.

Greetings,
Wessel
Nov 17 '05 #2

P: n/a
Hi,

I think that Suspend will suspend only when thread is in safe (managed)
state - this rules out unmanaged execution suspension.
Anyway, it is not a good practice to use Thread.Suspend at all as it is
unpredictable - instead use synchronization mechanisms.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

"[Yosi]" <Yo**@discussions.microsoft.com> wrote in message
news:B5**********************************@microsof t.com...
Hi,
I create a thread which load DLL and have DLL function call,this Dll
function takes a lot of time.
My Question is , if I request Thread.Susspend(), and the thread is inside
the Dll function (Dll function not finished yet, and thread function wait
for
this function (DLL)call to compleate), what will happen ? is this will
susspend also the Dll function execution ? or will delay the susspend
untill
this function returned ?

Thx

Nov 17 '05 #3

P: n/a

"[Yosi]" <Yo**@discussions.microsoft.com> wrote in message
news:B5**********************************@microsof t.com...
Hi,
I create a thread which load DLL and have DLL function call,this Dll
function takes a lot of time.
My Question is , if I request Thread.Susspend(), and the thread is inside
the Dll function (Dll function not finished yet, and thread function wait
for
this function (DLL)call to compleate), what will happen ? is this will
susspend also the Dll function execution ? or will delay the susspend
untill
this function returned ?

Thx


If you mean your thread is executing a native code DLL function, then the
Thread.Suspend call will wait until the function returns from unmanaged
code. But you should NEVER use Thread.Suspend/Resume, it's way to dangerous
to use and these methods will be removed from the next version of the
framework. You should use managed synchronization primitives like
Monitor.Enter, Monitor.Wait , Monitor.Pulse, or WaitHandle.WaitOne instead.

Willy.

Nov 17 '05 #4

P: n/a
> If you mean your thread is executing a native code DLL function, then the
Thread.Suspend call will wait until the function returns from unmanaged
code.


Interesting, could you explain that in more detail?

I thought Thread.Suspend would call the ::SuspendThread() API, which ought
to stop a native code DLL function from executing.

Greetings,
Wessel
Nov 17 '05 #5

P: n/a

"Wessel Troost" <no*****@like.the.sun> wrote in message
news:op.suiu09wef3yrl7@asbel...
If you mean your thread is executing a native code DLL function, then the
Thread.Suspend call will wait until the function returns from unmanaged
code.


Interesting, could you explain that in more detail?

I thought Thread.Suspend would call the ::SuspendThread() API, which ought
to stop a native code DLL function from executing.

Greetings,
Wessel


The Thread.Suspend service in the CLR calls Win32 SuspendThread() API when
it's safe to call it from the CLR's point of view, that is when the code has
reached a safe point (in managed code) for the GC to run. When your thread
runs in unmanaged code land, the CLR is no longer controlling the execution
environment so it's considered dangerous to suspend a thread cold (it's even
dangerous to call SuspendThread in pure unmanaged code).

When running managed code you should never forget that the CLR (EE, JIT, GC
etc...) controls the run-time environment and the services called from the
underlying OS. That's why it might be 'dangerous' to bypass the CLR (and/or
the FCL) and call directly into Win32 through PInvoke to execute certain OS
services.

Willy.


Nov 17 '05 #6

P: n/a
> The Thread.Suspend service in the CLR calls Win32 SuspendThread() API
when
it's safe to call it from the CLR's point of view, that is when the code
has
reached a safe point (in managed code) for the GC to run. When your
thread
runs in unmanaged code land, the CLR is no longer controlling the
execution
environment so it's considered dangerous to suspend a thread cold (it's
even
dangerous to call SuspendThread in pure unmanaged code).

Thanks for the explanation.

The documentation says SuspendThread is a "debugger" facility, and should
not be used for thread synchronisation. It also says:

Calling SuspendThread on a thread that owns a synchronization object, such
as a mutex or critical section, can lead to a deadlock if the calling
thread tries to obtain a synchronization object owned by a suspended
thread.

Sounds like it's a good function to avoid :)

Greetings,
Wessel
Nov 17 '05 #7

P: n/a
OK,
I try other option but I still miss somthing , by handle the stat by
parameter of thread,from the father (FORM) when user click on susspend I
change the handle to be suspenrequest, in the thread(call DLL function) after
returning from Dll function call , the thread read the value of the handle if
suspendrequest I do Thread.CurrentThread.Susspend. and change the father
handle stat to be susspend,if not I call Dll function again (this is the
thread, call Dll function in loop).

If this Ok , I have a problem! , when user click on susspend I change the
state to susspenrequest,and wait to thread become susspeneded by read the
thread stat. in this case I sould wait in loop without doing any thing, but
if I do the following :

threadHandler.Susspend();
//Wait for Thread to susspend
do
{
read state if susspend then break;
}
while(true)

the thread(DLL) will not get focuse and it will never continue I don't know
whay ?, why that? the application will stuck in this loop and never continue
execution the thread.

If I try to use Sleep it also Sleep the thread(DLL), How I solve this problem?
Why I can't use Thread.Sleep in the click function inside while as following ?
threadHandler.Susspend();

//Wait for Thread to susspend
do
{
read state if susspend then break;
Thread.Sleep(200);
}
while(true)

Yosi.
"Miha Markic [MVP C#]" wrote:
Hi,

I think that Suspend will suspend only when thread is in safe (managed)
state - this rules out unmanaged execution suspension.
Anyway, it is not a good practice to use Thread.Suspend at all as it is
unpredictable - instead use synchronization mechanisms.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

"[Yosi]" <Yo**@discussions.microsoft.com> wrote in message
news:B5**********************************@microsof t.com...
Hi,
I create a thread which load DLL and have DLL function call,this Dll
function takes a lot of time.
My Question is , if I request Thread.Susspend(), and the thread is inside
the Dll function (Dll function not finished yet, and thread function wait
for
this function (DLL)call to compleate), what will happen ? is this will
susspend also the Dll function execution ? or will delay the susspend
untill
this function returned ?

Thx


Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.