Aborted threads and released locks

  • Thread starter Thread starter gs_sarge
  • Start date Start date
G

gs_sarge

Hello:

I have a simple question.

If a thread1 has a lock on an object, but thread2 calls
thread1.Abort() on thread1 before thread1 releases the lock, is the
lock automatically released or is it frozen?

thanks for any help given.

steve
 
You have to be careful here. If you are using a Monitor make sure you lock
using the lock statement (synclock in VB.NET) to lock the objects. This
internally would create a try catch block with a finally clause where the
Moniter.Exit is called. If Monitor.Enter and Exit are used directly (not
recommended), then you might have a case where the locks are not released
when the thread is aborted( a case where Monitor.Exit is not called before
the thread is aborted)
I dont think this problem is there with Mutexes though. But again, if you
are using other waithandles like resetevents (manual or auto) and depend on
singnalling, then you need to make sure that the Set method is called in
your finally block of the method (in the thread which is aborted).
 
I tested this with mutex and lock (and maybe monitor). Not too hard to test
and see that behavior. IIRC, the lock is granted to the next thread waiting
on the lock. The win32 mutex at least gives you the WaitAborted message,
but the .net locks do not AFAICT. This is kinda dangerous to not notify the
next thread via some exception, but on the otherhand, your control program
should catch the thread abort from the aborted thread - so its not like your
program will not have a clue something has gone wrong. I would think thread
abort is probably fatal to program anyway, so your app may want to shutdown
anyway or restart, etc.
 
William Stacey said:
I tested this with mutex and lock (and maybe monitor). Not too hard to test
and see that behavior. IIRC, the lock is granted to the next thread waiting
on the lock. The win32 mutex at least gives you the WaitAborted message,
but the .net locks do not AFAICT. This is kinda dangerous to not notify the
next thread via some exception, but on the otherhand, your control program
should catch the thread abort from the aborted thread - so its not like your
program will not have a clue something has gone wrong. I would think thread
abort is probably fatal to program anyway, so your app may want to shutdown
anyway or restart, etc.
Click to expand...
Small point: threadAborts are not fatal to an entire program. They are
injected into all threads in an appdomain when the appdomain is being
unloaded so that the threads may be unwound to the appdomain boundary. They
can also be manually injected by application code so this is an application
choice. In v1.0 and v1.1 a thread abort can prematurely terminate code
executing in a finally block so injecting a thread abort into a thread from
another thread is not recommended.

Interestingly when an application is terminating thread aborts are not used.
Instead all threads are frozen, finalizers are run, and then the app is
terminated (it's actually more complicated but that's it in a nutshell).
 
Small point: threadAborts are not fatal to an entire program. They are
injected into all threads in an appdomain when the appdomain is being
unloaded so that the threads may be unwound to the appdomain boundary.
Click to expand...
They

Sorry for confusion, I did not expand enouph. As you don't know what locks
the thread had or what it did while it had the locks, it is most likely
~fatal to your data structures the locks where protecting. You could have
counters out of wack, head and tail pointers pointing to wrong places, and
on and on. In that regard, it may be the best thing to just close down as
cleanly as possible instead of running with possibablly bad data. That is
what I meant by "fatal" to your program, not that the thread abort exception
is fatal in and of itself. Cheers.
 
thank you. that's good to know

Small point: threadAborts are not fatal to an entire program. They are
injected into all threads in an appdomain when the appdomain is being
unloaded so that the threads may be unwound to the appdomain boundary. They
can also be manually injected by application code so this is an application
choice. In v1.0 and v1.1 a thread abort can prematurely terminate code
executing in a finally block so injecting a thread abort into a thread from
another thread is not recommended.

Interestingly when an application is terminating thread aborts are not used.
Instead all threads are frozen, finalizers are run, and then the app is
terminated (it's actually more complicated but that's it in a nutshell).
Click to expand...
 
Back
Top