Friday, October 2, 2009

WPF, locks in paint and reentry bugs

Going off-off topic for this blog, but hey - I'm a software developer, this is what I do day to day.

I've recently came across the most puzzling bug. While porting some application from WinForms to a combination of WinForms/WPF environment, I traced a situation where a call to paint was supposed to be blocked on a lock, but instead a different control's paint entered and altered a shared class's internals. The result was the wrong presentation on the original paint. It was very hard to trace this bug.

I found the following related resources:
MSDN discussion thread: Paint reentrancy during thread sleep

Potential solution:
Dispatcher.DisableProcessing Method

Explained in this article:
WPF Fundamentals: Threading Model (look for "reentrancy and locking" segment)

For me - the bug isn't resolved yet. I'm still looking into ways to prevent the trace. The lock in paint here is unavoidable as it waits on access to video frame grabbers.

Update: - this is how I solved it, I added a push pop mechanism to the data that was changed internally inside the paint functions. Since the error was caused by lock not preventing paint reentry - the sequence was within one thread and sequential. Therefor the push/pop mechanism is assumed to have solved it.

I know no one cares, well - I hope you enjoy my other content. It's my blog, this is what I'm doing/thinking.


1 comment:

  1. You weren't the only one. I have similar issues in a Direct3D/Winforms application.

    I was a little disappointed in msdn for not warning about the side effects of Lock()ing on the ui thread. It now turns out that Parallel.For internally Lock()s, so you can't reliably use that in paint code either.

    I am going to try out DisableProcessing.