GC, Finalization, and thread-specific APIs

  • Thread starter Thread starter Brian Gideon
  • Start date Start date
B

Brian Gideon

How have you handled the finalization of thread-specific unmanaged
resources?

My question pertains specifically to using the DDEML which is a
thread-specific API. In other words, every call to the API using the
same handle must be made on the same thread as the one that obtained
the handle. Obviously, there is a conflict with the GC and the
finalizer thread in cases where the programmer forgets to call Dispose
on a wrapper class.

I have a solution that I have been using for 3 or 4 years now and it
seems to work, but to be honest I'm not positive that it is the right
one. I'm just now beginning to explore the pitfalls of finalization on
thread-specific resources in a careful manner.

Basically what I have is this:

protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// Cleanup managed resources.
}

if (Thread.CurrentThread.ManagedThreadId == knownThreadId)
{
DdeDisconnect(handle);
}
else
{
PostThreadMessage(knownThreadId, WM_MYUSERMSG, handle,
IntPtr.Zero);
}
}
}

Of course, I have to install an IMessageFilter on the target thread
first. The implementation would be:

bool IMessageFilter.PreFilterMessage(ref Message m)
{
if (m.Msg == WM_MYUSERMSG)
{
DdeDisconnect(m.wParam);
return true;
}
return false;
}

It seems clean, but there are situations where DdeDisconnect will never
be called and I realize that. In most circumstances this seems to work
well.
 
Anyone have an opinion or alternative approach? If not, I'll stick
with what I have.
 
I did not evaluate the correctness of the code snippet itself; there is a
possibility that the call to DdeDisconnect will never occur, regardless of
other concerns.

The finalizer will never get called on the same thread as that used by the
code that created the object, so the alternative code path (posting a
message to the window/thread that created the object) will be used. The
concern would when the application was exiting and the runtime is shutting
down, or the appdomain the code is running in is getting destroyed. There
are no guarantees made about the order that finalizers will be called in, so
there is a possibility that the window you are posting the message to has
already been destroyed. In this case the call to DdeDisconnect may never
occur since the window or thread may already have been destroyed. It's even
possible that the runtime's infrastructure for delivering messages has
already been torn down.

The real question is what the side-effects are of not cleaning up the dde
connection. If there are none then your workaround may work as intended, but
if it means that the client or server on the other end never cleans up its
connection then you may have a resouce leak on the other end. How resilient
is the Dde client/server you are connected to? Many of them are poorly
written (the dde protocol itself is horrible). If the Ddeml layer cleans up
behind connections that disappear without following the defined shutdown
semantics then you may be ok, but in my experience dde apps are flaky.

If these are legitimate concerns then I would run the entire dde connection
on a separate thread created and managed by the class that encapsulates the
interface to the ddeml layer, and marshal all dde messages to and from this
thread from other threads. You can create a hidden window on this thread to
serve as the target of dde messages. When the object is finalized,
regardless of the thread calling Dispose or the finalizer, you can signal
the worker thread to shutdown and cleanup, and the other thread can block
until that has completed. That way the lifetime of the thread that the dde
connection is created on, and the window used to send and receive messages,
is entirely under your control.

Just some thoughts,
Dave
 
Thanks for the feedback.

David said:
I did not evaluate the correctness of the code snippet itself; there is a
possibility that the call to DdeDisconnect will never occur, regardless of
other concerns.
Click to expand...

Yep. And I'm not sure if I can completely fix that or that I even want
to put forth effort in attempting to do so.
The finalizer will never get called on the same thread as that used by the
code that created the object, so the alternative code path (posting a
message to the window/thread that created the object) will be used. The
concern would when the application was exiting and the runtime is shutting
down, or the appdomain the code is running in is getting destroyed. There
are no guarantees made about the order that finalizers will be called in, so
there is a possibility that the window you are posting the message to has
already been destroyed. In this case the call to DdeDisconnect may never
occur since the window or thread may already have been destroyed. It's even
possible that the runtime's infrastructure for delivering messages has
already been torn down.
Click to expand...

Absolutely. I'm quite positive that it is happening.
The real question is what the side-effects are of not cleaning up the dde
connection. If there are none then your workaround may work as intended, but
if it means that the client or server on the other end never cleans up its
connection then you may have a resouce leak on the other end. How resilient
is the Dde client/server you are connected to? Many of them are poorly
written (the dde protocol itself is horrible). If the Ddeml layer cleans up
behind connections that disappear without following the defined shutdown
semantics then you may be ok, but in my experience dde apps are flaky.
Click to expand...

DDE being a horrible protocol is an understatement. Its days are
numbered. Of course, that's what I thought 5 years ago. Anyway, I
think the DDEML is robust enough to clean up orphaned connections. I
say that because I can observe that a server will receive the
disconnect message even when a client process as been terminated
unconditionally via a kill command or whatever.
If these are legitimate concerns then I would run the entire dde connection
on a separate thread created and managed by the class that encapsulates the
interface to the ddeml layer, and marshal all dde messages to and from this
thread from other threads. You can create a hidden window on this thread to
serve as the target of dde messages. When the object is finalized,
regardless of the thread calling Dispose or the finalizer, you can signal
the worker thread to shutdown and cleanup, and the other thread can block
until that has completed. That way the lifetime of the thread that the dde
connection is created on, and the window used to send and receive messages,
is entirely under your control.
Click to expand...

Actually, that's exactly what I do. The added benefit of maintaining a
dedicated thread for DDE message pumping is that it will work in
console and service applications as well. Unfortunately, it doesn't
help in finalization for the same reasons you already mentioned. That
dedicated thread or the hidden window used to pump messages could be
finalized before the code has processed the message to call
DdeDisconnect.

The intent of my post was not to discuss DDE specifically, but to have
a general discussion so that anyone else forced to use a
thread-specific API could benefit from it as well.
 
DDE being a horrible protocol is an understatement. Its days are
numbered. Of course, that's what I thought 5 years ago. Anyway, I
think the DDEML is robust enough to clean up orphaned connections. I
say that because I can observe that a server will receive the
disconnect message even when a client process as been terminated
unconditionally via a kill command or whatever.
Click to expand...

The first windows app (win3.0) I wrote was a dde server...way before ddeml
was even available. DDE has been dying for over 10 years but it aint dead
yet. Anyway, the question is not just whether or not ddeml is robust enough,
it's also if the client or server that is connected to the .net app that
just died is robust enough to survive an unclean shutdown.

Actually, that's exactly what I do. The added benefit of maintaining a
dedicated thread for DDE message pumping is that it will work in
console and service applications as well. Unfortunately, it doesn't
help in finalization for the same reasons you already mentioned. That
dedicated thread or the hidden window used to pump messages could be
finalized before the code has processed the message to call
DdeDisconnect.
Click to expand...

A couple more thoughts about this....there is an additional problem with
trying to cleanup the dde connection from inside the finalizer during system
shutdown. When shutting down the runtime suspends all threads and does not
ever resume them; the only thread that is allowed to run is the finalizer
thread. This effectively means that you will never pump messages during
system shutdown.

However, there is a way that might work around this problem. You can
subscribe to the AppDomain.ProcessExit event This event gets fired before
the threads get suspended, so if you force all ddeml cleanup to occur during
this event you will still be able to pump messages to the dde windows.

But there's another "but"....this event only gets delivered to the default
appdomain (at least, for v1.1; I'm not sure about 2.0), so if you are doing
DDE from other appdomains you cannot rely on this for cleanup. You will
either have to use the default appdomain for all DDE, or you will have to
write your own plumbing to forward the ProcessExit event from the default
appdomain to all secondary appdomains.

Of course, if the ddeml layer and all connected apps are robust enough to
survive this then it doesn't matter - ignore it and be happy.
The intent of my post was not to discuss DDE specifically, but to have
a general discussion so that anyone else forced to use a
thread-specific API could benefit from it as well.
Click to expand...

Most of this discussion is related to dealing with unmanaged resources that
have thread affinity issues, and how the runtime does not do such a great
job of providing tools and hooks to provide for complete shutdown/cleanup
semantics. It's not that it can't be done, but it's not so easy or obvious
where the jack-in-the-box (surprise!) moments are. However, I think we can
all agree that dde sucks (why the heck are you still using it???)

cheers,
Dave
 
David said:
<snip>

A couple more thoughts about this....there is an additional problem with
trying to cleanup the dde connection from inside the finalizer during system
shutdown. When shutting down the runtime suspends all threads and does not
ever resume them; the only thread that is allowed to run is the finalizer
thread. This effectively means that you will never pump messages during
system shutdown.

However, there is a way that might work around this problem. You can
subscribe to the AppDomain.ProcessExit event This event gets fired before
the threads get suspended, so if you force all ddeml cleanup to occur during
this event you will still be able to pump messages to the dde windows.
Click to expand...

Interesting. I hadn't thought about using that event.
But there's another "but"....this event only gets delivered to the default
appdomain (at least, for v1.1; I'm not sure about 2.0), so if you are doing
DDE from other appdomains you cannot rely on this for cleanup. You will
either have to use the default appdomain for all DDE, or you will have to
write your own plumbing to forward the ProcessExit event from the default
appdomain to all secondary appdomains.
Click to expand...

Thanks for the heads up. I wouldn't have thought of that.
Of course, if the ddeml layer and all connected apps are robust enough to
survive this then it doesn't matter - ignore it and be happy.

Most of this discussion is related to dealing with unmanaged resources that
have thread affinity issues, and how the runtime does not do such a great
job of providing tools and hooks to provide for complete shutdown/cleanup
semantics. It's not that it can't be done, but it's not so easy or obvious
where the jack-in-the-box (surprise!) moments are. However, I think we can
all agree that dde sucks (why the heck are you still using it???)
Click to expand...

Yes. DDE definitely sucks. The PLC and SCADA industry is behind the
times as far as Windows software is concerned. Most have moved on to
better things (ie. OPC), but there are stragglers who only provide DDE
support. There is light at the end of the tunnel though. Some players
in the industry have expressed interest in providing .NET APIs.
 
Yes. DDE definitely sucks. The PLC and SCADA industry is behind the
times as far as Windows software is concerned. Most have moved on to
better things (ie. OPC), but there are stragglers who only provide DDE
support. There is light at the end of the tunnel though. Some players
in the industry have expressed interest in providing .NET APIs.
Click to expand...

We work in the same or a related industry - I work with PLCs too for one of
the manufacturers. OPC is better but it would be even better if the whole
industry moved to .net. Probably wont happen for many years.

Good luck.
Dave
 
Back
Top