Here’s a puzzle for you guys. I have a multithreaded program in which some threads work with managed resources like locks and semaphores. Some of the lock release primitives can only be performed from the same thread on which the lock acquire was done.
So here’s my puzzle: I wrap these kinds of operations: try { lock-acquire… do something } finally { lock-release }, but sometimes when my threads terminate, the finally clauses are performed by the .NET garbage collection thread and not by my thread. (The specific case actually involves the Dispose of an object allocated in a “using” statement; see below for details)
This is a little tricky to demo; I see it all the time in Isis2, and I’ve figured out that this is happening by checking the thread-ids in the acquire and finalize blocks. But I don’t have a 3-line demo for you, and I am sorry about that. I know it would make it easier to provide help.
Is there a way I can delay termination for a thread until all pending finalize blocks associated with that thread have executed?
—- Details added for Mark —-
What I’m really doing involves a fairly elaborate self-instrumenting locking package that has various locking abstractions (bounded buffers, barriers, normal locks, etc) with thread priorities and designed to self-detect deadlocks, priority inversions, very slow lock grants and other problems. My code is complex enough and threaded enough so that I needed this to debug it.
An example of my basic style of construct is this:
LockObject myLock = new LockObject("AnIsis2Lock");
...
using(new LockAndElevate(myLock)) { stuff }
A LockObject is a self-monitoring lock… a LockAndElevate makes note that I locked it (in this case) and later tracks the dispose, when I unlock it. So I’m exploiting the fact that using should dispose of the new object when the block completes — even if it throws an exception.
What I’m seeing is that fairly often, threads terminate and yet the using dispose events haven’t actually occurred; they run later, on some other thread. This only happens when one of my threads terminates; in normal execution, the whole thing works like a charm.
So since using translates to try… finally, my question was posted in terms of finally clauses.
So as of now, here’s my best answer to my own question, based mostly on experience debugging the behavior of Isis2.
If threads don’t terminate, “using(x = new something()) { }” (which maps to “try { x= new something(); …} finally { x.dispose }”) works precisely as you would expect: the dispose occurs when the code block is exited.
But exceptions disrupt the control flow. So if your thread throws an IsisException, or something down in “something” does so, control passes to the catch for that exception. This the case I’m dealing with, and my catch handler is higher on the stack. C#/.NET faces a choice: does it catch the IsisException first, or does it do the dispose first? In this case I’m fairly certain the system systematically does the IsisException first. As a result, the finalizer for the allocated object “x” has not yet executed but is runable and needs to be called soon.
[NB: For those who are curious, the Using statement ends by calling Dispose, but the recommended behavior, per the documentation, is to have a finalizer ~something() { this.Dispose; } just to cover all possible code paths. Dispose might then be called more than once and you should keep a flag, locked against concurrency, and dispose your managed resources only on the first call to Dispose.]
Now the key problem is that the finalizer apparently might not run before your thread has a chance to terminate in this case of a caught exception that terminates your thread; if not, C# will dispose of the object by calling dispose on a GC finalizer thread. As a result if, as in my code, x.Dispose() unlocks something an error can occur: a lock acquire/release must occur in the same thread on .NET. So that’s a source of potential bugs for you and for me! It seems that calling GC.WaitForFinalizers in my exception handler helps in this case. Less clear to me is whether this is a true guarantee that bad things won’t occur.
A further serious mistake in my own code was that I had erroneously been catching ThreadAbortException in a few threads, due to an old misunderstanding about how those work. Don’t do this. I can see now that it causes serious problems for .NET. Just don’t use Thread.Abort, ever.
So on the basis of this understanding, I’ve modified Isis2 and it works nicely now; when my threads terminate the finalizers do appear to run correctly, dispose does seem to happen before the thread exits (and hence before its id can be reused, which was causing me confusion), and all is good for the world. Those who work with threads, priorities, and self-managed locks/barriers/bounded buffers and semaphores should be cautious: there are dragons lurking here!