Re: thread.Abort()

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Jeffrey Wynn (sonofsheaf_at_optonline.net)
Date: 02/16/04 

Date: Mon, 16 Feb 2004 09:07:23 -0500

Here is a link to some MSDN documentation that explains some of the
threading concepts that were referenced in this thread and how they are
dealt with in the .NET Framework.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmanagedthreadingsupport.asp

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconmanagedthreadingbestpractices.asp?frame=true

Hope this helps. 

--
Jeffrey Wynn
sonofsheaf@nospam.net
"Dave" <noSpamdlevineNNTP2@wi.rr.com> wrote in message
news:e7iHa0C9DHA.1804@TK2MSFTNGP12.phx.gbl...
>
> "Daisy" <daisy@nospam.oops> wrote in message
> news:c0oi8u$ra1$1@linux01.dannytuppeny.com...
> > "Dave" <noSpamdlevineNNTP2@wi.rr.com> wrote in message
> > news:ekMEIo$8DHA.3364@TK2MSFTNGP09.phx.gbl...
> > <snip>
> > > You are correct; there are many code snippets that ignore race
> conditions.
> > > Writing correct multithreaded code is a very difficult task and even
> > > thoroughly-tested production code can have threading bugs lurking in
it.
> > > There are also many people who think they know the issues but really
> > don't.
> >
> > Righto. But how *would* you overcome something like this? Say you wanted
> to
> > read a property from an object you're not sure still exists. You test it
> > exists first, but you've still got a race condition. Wrapping it in a
try
> > block would work, but is that the best way?
> > -- 
>
> If you have a reference to an object then the object will be around so
long
> as you hang onto the reference. The issue is not whether the memory is
still
> valid or not - as long as the reference is rooted the memory is still
> valid - the original issue is one of race conditions between threads.
>
> A try block does not help prevent race conditions, it only catches an
> exception that is thrown in the guarded block of code. The only way to
> prevent race conditions is to use synchronization mechanisms; the code
> snippet shown does absolutely nothing in this regard.
>
> Further, the entire premise of the code snippet shown is incorrect. There
> are many side-effects to inducing an abort exception asynchronously in
> another thread, all of them bad. For example, the target thread may be
> executing code in a finally block - this can be interrupted with unknown
> consequences. Another is that if the exception occurs while the target
> thread is executing code in a static constructor the type is rendered
> unusable in that appdomain.
>
> In addition thread objects continue to exist for some time even after the
> thread is no longer "alive" (holding a reference to the thread will do
> this), and if you call abort on a thread that is already terminated the
> request is ignored, so I still am mystified as to why the author of that
> article thought it necessary to call IsAlive prior to calling Abort.
>
> In the snippet...
>
> if ( t.IsAlive )
>   t.Abort();
>
> The amount of time that can elapse after calling IsAlive and before
> Thread.Abort is executed is unbounded. The call to IsAlive can indicate
the
> target thread is alive but before the next line of code executes a context
> switch can occur, other code executes, and the target thread could
actually
> die. Even if the thread is still alive the amount of time it takes for the
> thread to actually terminate is also unbounded.
>
> One safe way for one thread to signal another thread to terminate is to
use
> a signalling mechanism, such as a ManualResetEvent, that the calling
thread
> sets to the signalled state and the target threads periodically checks.
This
> is a synchronous mechanism that allows the target thread to reach a known
> safe point in its execution path before it terminates. This is a
relatively
> standard technique. If you need to know when the thread has terminated you
> can wait on the thread object to become signalled (do a Join on the thread
> object).
>
> Dave
>
>
>
>

Relevant Pages

  • Re: thread.Abort()
    ... executing code in a finally block - this can be interrupted with unknown ... target thread is alive but before the next line of code executes a context ... One safe way for one thread to signal another thread to terminate is to use ... a signalling mechanism, such as a ManualResetEvent, that the calling thread ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: thread.Abort()
    ... >> as you hang onto the reference. ... the target thread may be ... >> switch can occur, other code executes, and the target thread could ... >> thread to actually terminate is also unbounded. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Thread Error in Delphi7
    ... but you'll only have a reference to the second one. ... It's best not to set change the FreeOnTerminate property after the ... thread might already be executing by the time execution reaches the ... the Terminate procedure has no effect. ...
    (alt.comp.lang.borland-delphi)
  • Delphi Trojans
    ... I have a component I have been working on that happened to reference a unit ... the controller unit for an application which instantiates a controller ... noticed that delphi was executing this code, which was logging into a server ... No longer will I download components without source code. ...
    (borland.public.delphi.non-technical)
  • Re: passing values from one for to another
    ... userforms in VBA on unload, ... I wanted each of these little objects to have a reference to ... their containing control, but worried that I was setting up a circular ... its Terminate event got fired (despite all the ...
    (microsoft.public.vb.general.discussion)