WP7 - Having trouble gracefully exiting bg thread on app deactivate or closing

Question

My somewhat data-intensive wp7 app persists data as follows: I maintain a change journal reflecting all user activity, and every couple of seconds, a thread timer spins up a threadpool thread that flushes the change journal to a database inside a transaction. It looks something like this:

When the user exits, I stop the timer, flush the journal on the UI thread (takes no more than a second or two), and dismount the DB.

However, if the worker thread is active when the user exits, I can't figure out how to react gracefully. The system seems to kill the worker thread, so it never finishes its work and never gives up its lock on the database connection, and the ui thread then attempts to acquire the lock, and is immediately killed by the system. I tried setting a flag on the UI thread requesting the worker to abort, but I think the worker was interrupted before it read the flag. Everything works fine except for this 1 in 100 scenario where some user changes end up not being saved to the db, and I can't seem to get around this.

Very simplified code below:

private Timer _SweepTimer = new Timer(SweepCallback, null, 5000, 5000);

private volatile bool _BailOut = false;
private void SweepCallback(object state) {
    lock (db) { 
        db.startTransaction();

        foreach(var entry in changeJournal){
            //CRUD entry as appropriate
            if(_BailOut){
                db.rollbackTransaction();
                return;
            }
        }

        db.endTransaction();
        changeJournal.Clear();
    }
}

private void RespondToSystemExit(){
    _BailOut = true; //Set flag for worker to exit

    lock(db){ //In theory, should acquire the lock after the bg thread bails out
        SweepCallback(null);//Flush to db on the UI thread
        db.dismount();//App is now ready to close
    }
}

Answer 1

Well, just to close this question, I ended up using a manualresetevent instead of the locking, which is to the best of my understanding a misuse of the manualresetevent, risky and hacky, but its better than nothing.

I still don't know why my original code wasn't working.

EDIT: For posterity, I'm reposting the code to reproduce this from the MS forums:

//This is a functioning console app showing the code working as it should. Press "w" and then "i" to start and then interrupt the worker
using System;
using System.Threading;

namespace deadlocktest {
    class Program {
        static void Main(string[] args) {
            var tester = new ThreadTest();
            string input = "";
            while (!input.Equals("x")) {
                input = Console.ReadLine();

                switch (input) {
                    case "w":
                        tester.StartWorker();
                        break;
                    case "i":
                        tester.Interrupt();
                        break;
                    default:
                        return;
                }
            }
        }
    }

    class ThreadTest{
        private Object lockObj = new Object();
        private volatile bool WorkerCancel = false;

        public void StartWorker(){
            ThreadPool.QueueUserWorkItem((obj) => {
                if (Monitor.TryEnter(lockObj)) {
                    try {
                        Log("Worker acquired the lock");
                        for (int x = 0; x < 10; x++) {
                            Thread.Sleep(1200);
                            Log("Worker: tick" + x.ToString());
                            if (WorkerCancel) {
                                Log("Worker received exit signal, exiting");
                                WorkerCancel = false;
                                break;
                            }
                        }
                    } finally {
                        Monitor.Exit(lockObj);
                        Log("Worker released the lock");
                    }
                } else {
                    Log("Worker failed to acquire lock");
                }
            });
        }

        public void Interrupt() {
            Log("UI thread - Setting interrupt flag");
            WorkerCancel = true;

            if (Monitor.TryEnter(lockObj, 5000)) {
                try {
                    Log("UI thread - successfully acquired lock from worker");
                } finally {
                    Monitor.Exit(lockObj);
                    Log("UI thread - Released the lock");
                }
            } else {
                Log("UI thread - failed to acquire the lock from the worker");
            }
        }

        private void Log(string Data) {
            Console.WriteLine(string.Format("{0} - {1}", DateTime.Now.ToString("mm:ss:ffff"), Data));
        }
    }
}

Here is nearly identical code that fails for WP7, just make a page with two buttons and hook them

using System;
using System.Diagnostics;
using System.Threading;
using System.Windows;
using Microsoft.Phone.Controls;

namespace WorkerThreadDemo {
    public partial class MainPage : PhoneApplicationPage {
        public MainPage() {
            InitializeComponent();
        }

        private Object lockObj = new Object();
        private volatile bool WorkerCancel = false;
        private void buttonStartWorker_Click(object sender, RoutedEventArgs e) {
            ThreadPool.QueueUserWorkItem((obj) => {
                if (Monitor.TryEnter(lockObj)) {
                    try {
                        Log("Worker acquired the lock");
                        for (int x = 0; x < 10; x++) {
                            Thread.Sleep(1200);
                            Log("Worker: tick" + x.ToString());
                            if (WorkerCancel) {
                                Log("Worker received exit signal, exiting");
                                WorkerCancel = false;
                                break;
                            }
                        }
                    } finally {
                        Monitor.Exit(lockObj);
                        Log("Worker released the lock");
                    }
                } else {
                    Log("Worker failed to acquire lock");
                }
            });
        }

        private void Log(string Data) {
            Debug.WriteLine(string.Format("{0} - {1}", DateTime.Now.ToString("mm:ss:ffff"), Data));
        }

        private void buttonInterrupt_Click(object sender, RoutedEventArgs e) {
            Log("UI thread - Setting interrupt flag");
            WorkerCancel = true;

            //Thread.Sleep(3000); UNCOMMENT ME AND THIS WILL START TO WORK! 
            if (Monitor.TryEnter(lockObj, 5000)) {
                try {
                    Log("UI thread - successfully acquired lock from worker");
                } finally {
                    Monitor.Exit(lockObj);
                    Log("UI thread - Released the lock");
                }
            } else {
                Log("UI thread - failed to acquire the lock from the worker");
            }
        }
    }
}

Answer 2

As Heinrich Ulbricht already said you have <=10 sec to finish your stuff, but you should block MainThread to get them.

It means that even if you have BG thread with much work to do, but your UI thread just does nothing in OnClosingEvent/OnDeactivatingEvent - you will not get your 10 seconds.

Our application actually does eternal wait on UI thread in closing event to allow BG thread send some data thru sockets.

Answer 3

Your approach should work when you operate from the Application_Deactivated or Application_Closing event. MSDN says:

There is a time limit for the Deactivated event to complete. The device may terminate the application if it takes longer than 10 seconds to save the transient state.

So if you say it just takes just a few seconds this should be fine. Unless the docs don't tell the whole story. Or your worker thread takes longer to exit than you think.