Resource usage of ThreadPool RegisterWaitForSingleObject

Question

I am writing a server application which processes request from multiple clients. For the processing of requests I am using the threadpool.

Some of these requests modify a database record, and I want to restrict the access to that specific record to one threadpool thread at a time. For this I am using named semaphores (other processes are also accessing these records).
For each new request that wants to modify a record, the thread should wait in line for its turn.

And this is where the question comes in:
As I don't want the threadpool to fill up with threads waiting for access to a record, I found the RegisterWaitForSingleObject method in the threadpool.
But when I read the documentation (MSDN) under the section Remarks:

New wait threads are created automatically when required. ...

Does this mean that the threadpool will fill up with wait-threads? And how does this affect the performance of the threadpool?

Any other suggestions to boost performance is more than welcome!

Thanks!

Answer 1

Your solution is a viable option. In the absence of more specific details I do not think I can offer other tangible options. However, let me try to illustrate why I think your current solution is, at the very least, based on sound theory.

Lets say you have 64 requests that came in simultaneously. It is reasonable to assume that the thread pool could dispatch each one of those requests to a thread immediately. So you might have 64 threads that immediately begin processing. Now lets assume that the mutex has already been acquired by another thread and it is held for a really long time. That means those 64 threads will be blocked for a long time waiting for the thread that currently owns the mutex to release it. That means those 64 threads are wasted on doing nothing.

On the other hand, if you choose to use RegisterWaitForSingleObject as opposed to using a blocking call to wait for the mutex to be released then you can immediately release those 64 waiting threads (work items) and allow them to be put back into the pool. If I were to implement my own version of RegisterWaitForSingleObject then I would use the WaitHandle.WaitAny method which allows me to specify up to 64 handles (I did not randomly choose 64 for the number of requests afterall) in a single blocking method call. I am not saying it would be easy, but I could replace my 64 waiting threads for only a single thread from the pool. I do not know how Microsoft implemented the RegisterWaitForSingleObject method, but I am guessing they did it in a manner that is at least as efficient as my strategy. To put this another way, you should be able to reduce the number of pending work items in the thread pool by at least a factor of 64 by using RegisterWaitForSingleObject.

So you see, your solution is based on sound theory. I am not saying that your solution is optimal, but I do believe your concern is unwarranted in regards to the specific question asked.

Answer 2

ThreadPool creates a wait thread for ~64 waitable objects.

Good comments are here: Thread.sleep vs Monitor.Wait vs RegisteredWaitHandle?

Answer 3

IMHO you should let the database do its own synchronization. All you need to do is to ensure that you're sync'ed within your process.

Interlocked class might be a premature optimization that is too complex to implement. I would recommend using higher-level sync objects, such as ReaderWriterLockSlim. Or better yet, a Monitor.

Answer 4

An approach to this problem that I've used before is to have the first thread that gets one of these work items be responsible for any other ones that occur while it's processing the work item(s), This is done by queueing the work items then dropping into a critical section to process the queue. Only the 'first' thread will drop into the critical section. If a thread can't get the critical section, it'll leave and let the thread already operating in the critical section handle the queued object.

It's really not very complicated - the only thing that might not be obvious is that when leaving the critical section, the processing thread has to do it in a way that doesn't potentially leave a late-arriving workitem on the queue. Basically, the 'processing' critical section lock has to be released while holding the queue lock. If not for this one requirement, a synchronized queue would be sufficient, and the code would really be simple!

Pseudo code:

// `workitem` is an object that contains the database modification request
//
// `queue` is a Queue<T> that can hold these workitem requests
//
//  `processing_lock` is an object use to provide a lock
//      to indicate a thread is processing the queue


// any number of threads can call this function, but only one
//  will end up processing all the workitems.
//
// The other threads will simply drop the workitem in the queue
//  and leave
void threadpoolHandleDatabaseUpdateRequest(workitem)
{
    // put the workitem on a queue
    Monitor.Enter(queue.SyncRoot);
    queue.Enqueue(workitem);
    Monitor.Exit(queue.SyncRoot);

    bool doProcessing;
    Monitor.TryEnter(processing_queue, doProcessing);
    if (!doProcessing) {
        // another thread has the processing lock, it'll
        //  handle the workitem
        return;
    }

    for (;;) {

        Monitor.Enter(queue.SyncRoot);
        if (queue.Count() == 0) {
            // done processing the queue

            // release locks in an order that ensures 
            // a workitem won't get stranded on the queue

            Monitor.Exit(processing_queue);
            Monitor.Exit(queue.SyncRoot);
            break;
        }

        workitem = queue.Dequeue();
        Monitor.Exit(queue.SyncRoot);

        // this will get the database mutex, do the update and release 
        //  the database mutex
        doDatabaseModification(workitem); 
    }
}