Stopping a multi-threaded windows service

Question

I have a multi-thread windows service in .Net 3.5, and I am having some trouble to stop the service properly when more than one thread is created.

This service used to create only one thread to do all the work, and I just changed it to be multi-threaded. It works perfectly, but when the service is stopped, if more than one thread is being executed, it will hang the service until all the threads are completed.

When the service is started, I create a background thread to handle the main process:

    protected override void OnStart(string[] args)
    {
        try
        {
            //Global variable that is checked by threads to learn if service was stopped
            DeliveryConstant.StopService = false;
            bool SetMaxThreadsResult = ThreadPool.SetMaxThreads(10, 10);

            ThreadStart st = new ThreadStart(StartThreadPool);
            workerThread = new Thread(st);
            workerThread.IsBackground = true;
            serviceStarted = true;
            workerThread.Start();
        }
        catch (Exception ex)
        {
            //Log something;
        }

Here is the StartThreadPool method:

    //Tried with and without this attribute with no success...
    [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.Synchronized)]
    public void StartThreadPool()
    {
        while (serviceStarted)
        {
            ProcessInfo input = new ProcessInfo();

            try
            {
                int? NumPendingRequests = GetItems(50, (Guid?)input.ProcessID);

                if (NumPendingRequests > 0)
                {
                    input.ProcessType = 1;
                    input.ProcessID = Guid.NewGuid();
                    ThreadPool.QueueUserWorkItem(new WaitCallback(new DispatchManager().ProcessRequestList), input);
                 }
            }
            catch (Exception ex)
            {
                //Some Logging here
            }
        }

        DeliveryConstant.StopService = true;
    }

I created a static variable in a separated class to notify the threads that the service was stopped. When the value for this variable is true, all threads should stop the main loop (a for each loop):

        public static bool StopService;

Finally, the OnStop method:

protected override void OnStop()
    {
        DeliveryConstant.StopService = true;

        //flag to tell the worker process to stop
        serviceStarted = false;

        workerThread.Join(TimeSpan.FromSeconds(30));
    }

In the ProcessRequestList method, at the end of every foreach, I check for the value of the StopService variable. If true, I break the loop.

Here is the problem: The threads are created in chunks of 50 items. When I have 50 items or less in the database, only one thread is created, and everything works beautifully. When I have more than 50 items, multiple threads will be created, and when I try to stop the service, it doesn't stop until all the background threads are completed.

From the logs, I can see that the method OnStop is only executed AFTER all threads are completed.

Any clue what could be changed to fix that?

Answer 1

This blog answer states that OnStop isn't called until all ThreadPool tasks complete, which is news to me but would explain your issue.

I've fielded many multi-threaded Windows Services but I prefer to create my own background threads rather than use the ThreadPool since these are long-running threads. I instantiate worker classes and launch their DoWork() method on the thread. I also prefer to use callbacks to the launching class to check for a stop signal and pass status rather than just test against a global variable.

Answer 2

You are missing memory barriers around accesses to StopService, which may be a problem if you have multiple CPUs. Better lock any reference object for ALL accesses to the shared variable. For example:

object @lock;

...

lock (@lock)
{
    StopService = true;
}

Edit: As another answer has revealed, this issue was not a locking problem, but I am leaving this answer here as a thing to check with multithread synchronization schemes.

Making the shared variable volatile would work in many cases as well, but it is more complex to prove correct because it does not emit full fences.