Prev: HttpWebRequest issue with HTTPS via WP7 Silverlight
Next: latest version of .net
From: Tony Johansson on 19 Jun 2010 20:44
Hello!

Here is some text from a book.
"Controlling threads in your applications often requires that you be able to
stop threads. The primary mechanism for stopping threads is to use the
Thread.Abort method. When the Thread.Abort method is called, the threading
system prepares to throw a ThreadAbortException in the thread. Whether the
exception is caught or not, the thread is stopped after it is thrown. The
following code snippet provides an example:

Thread newThread = new Thread(new ThreadStart(AbortThisThread));
newThread.Start();
newThread.Abort();

static void AbortThisThread()
{
//Setting data
SomeClass.IsValid = true;
SomeClass.IsComplete = true;

//Write the object to the console
SomeClass.WriteToConsole();
}

Because the AbortThisThread method never catches the ThreadAbortException,
this thread stops at the line currently executing when the main thread calls
Abort to kill the thread. This is a problem because the thread system
doesn't know where it can safely kill the thread. Aborting the thread in the
wrong place in the code could leave data in an inconsistent state. For
example, if the ThreadAbortException is thrown between the setting of the
IsValid and IsComplete properties, the SomeClass object might be left in an
inconsistent state. If the ThreadAbortException is thrown after the code
writes the properties but before the code calls the WriteToConsole method,
our object will be consisten. It will never write itself out to the console.
To solve the problem of leaving objects or the AppDomain in an inconsisten
state, the Thread class has two important static methods:
BeginCriticalRegion and EndCriticalRegion. We can add calls to these method
to tell the threading system that it can abort this thread, just not within
this critical region. The following code snippet provides an example:

static void AbortthisThread()
{
//Setting data
Thread.BeginCriticalRegion();
SomeClass.IsValid = true;
SomeClass.IsComplete = true;
Thread.EndCriticalRegion();

//Write the object to the console
SomeClass.WriteToConsole();
}

The idea behind a critical region is to provide a region of code that must
be executed as if it were a single statement Any attempt to abort a thread
while it is within a critical region will have to wait until after the
critical region is complete. At that point, the thread will be aborted,
throwing the ThreadAbortException."

As I mentioned all the text above is from a book.

As far as I understand and base on what you have been answered before this
text above is completely wrong about what is true when talking about
aborting code that is the executing code within a critical region. It just
signals to the host(.NET framework) that it should not abort that thread if
possible, but if it does abort the thread, it should tear down the entire
AppDomain.

The follwong text from above is complete wrong The idea behind a critical
region is to provide a region of code that must be executed as if it were a
single statement Any attempt to abort a thread while it is within a critical
region will have to wait until after the critical region is complete.

Do you agree with me ?

//Tony



From: Peter Duniho on 19 Jun 2010 21:19
Tony Johansson wrote:
> [...]
> As far as I understand and base on what you have been answered before this
> text above is completely wrong about what is true when talking about
> aborting code that is the executing code within a critical region. It just
> signals to the host(.NET framework) that it should not abort that thread if
> possible, but if it does abort the thread, it should tear down the entire
> AppDomain.
>
> The follwong text from above is complete wrong The idea behind a critical
> region is to provide a region of code that must be executed as if it were a
> single statement Any attempt to abort a thread while it is within a critical
> region will have to wait until after the critical region is complete.
>
> Do you agree with me ?

I agree that the book you are using continues to be a very poor source
of information, and that it is simply untrue that Thread.Abort() is even
a reasonable, never mind "primary" mechanism for stopping threads. I
pointed that out the last time you quoted that passage of text.

Thread management should be done cooperatively, with synchronization
objects to allow communication between threads, so that a thread that
should stop can be told to stop, at which point it can do so on its own,
in a way that ensures the data it's working on remains in a consistent
state.

It is true that you can use critical execution regions to try to prevent
a thread abort from occurring in a place where it would be especially
bad to occur. But this is not something that should be used as a normal
practice for controlling threads. And a CER does not ensure that the
code is permitted to continue to run until the end of the CER; the CLR
host has the option of simply tearing down the entire AppDomain, which
of course makes any question of data integrity moot, because your data
is gone at that point.

Pete
From: Arne Vajhøj on 19 Jun 2010 21:31
On 19-06-2010 20:44, Tony Johansson wrote:
> Here is some text from a book.
> "Controlling threads in your applications often requires that you be able to
> stop threads. The primary mechanism for stopping threads is to use the
> Thread.Abort method.

I don't think this is correct.

The primary mechanism is to set a flag that the code in the thread
test on at a convenient time.

> When the Thread.Abort method is called, the threading
> system prepares to throw a ThreadAbortException in the thread. Whether the
> exception is caught or not, the thread is stopped after it is thrown. The
> following code snippet provides an example:
>
> Thread newThread = new Thread(new ThreadStart(AbortThisThread));
> newThread.Start();
> newThread.Abort();
>
> static void AbortThisThread()
> {
> //Setting data
> SomeClass.IsValid = true;
> SomeClass.IsComplete = true;
>
> //Write the object to the console
> SomeClass.WriteToConsole();
> }
>
> Because the AbortThisThread method never catches the ThreadAbortException,
> this thread stops at the line currently executing when the main thread calls
> Abort to kill the thread. This is a problem because the thread system
> doesn't know where it can safely kill the thread. Aborting the thread in the
> wrong place in the code could leave data in an inconsistent state. For
> example, if the ThreadAbortException is thrown between the setting of the
> IsValid and IsComplete properties, the SomeClass object might be left in an
> inconsistent state. If the ThreadAbortException is thrown after the code
> writes the properties but before the code calls the WriteToConsole method,
> our object will be consisten. It will never write itself out to the console.
> To solve the problem of leaving objects or the AppDomain in an inconsisten
> state, the Thread class has two important static methods:
> BeginCriticalRegion and EndCriticalRegion. We can add calls to these method
> to tell the threading system that it can abort this thread, just not within
> this critical region. The following code snippet provides an example:
>
> static void AbortthisThread()
> {
> //Setting data
> Thread.BeginCriticalRegion();
> SomeClass.IsValid = true;
> SomeClass.IsComplete = true;
> Thread.EndCriticalRegion();
>
> //Write the object to the console
> SomeClass.WriteToConsole();
> }
>
> The idea behind a critical region is to provide a region of code that must
> be executed as if it were a single statement Any attempt to abort a thread
> while it is within a critical region will have to wait until after the
> critical region is complete. At that point, the thread will be aborted,
> throwing the ThreadAbortException."
>
> As I mentioned all the text above is from a book.
>
> As far as I understand and base on what you have been answered before this
> text above is completely wrong about what is true when talking about
> aborting code that is the executing code within a critical region. It just
> signals to the host(.NET framework) that it should not abort that thread if
> possible, but if it does abort the thread, it should tear down the entire
> AppDomain.
>
> The follwong text from above is complete wrong The idea behind a critical
> region is to provide a region of code that must be executed as if it were a
> single statement Any attempt to abort a thread while it is within a critical
> region will have to wait until after the critical region is complete.
>
> Do you agree with me ?

It is documented at:

http://msdn.microsoft.com/en-us/library/system.threading.thread.begincriticalregion.aspx

Arne
 | 
Pages: 1
Prev: HttpWebRequest issue with HTTPS via WP7 Silverlight
Next: latest version of .net