Framework Design: Multithreaded Data Request Threadpool Model

C

Cyrilix

2[H]4U
Joined
Jan 21, 2005
Messages
2,188
I'm looking for some feedback on a multithreaded data request model. My idea can be summarized in the following image:



I'm sure someone will ask me why I'm interested in doing this -- well, partially for fun, and partially as a component of a personal project that I'm working on. My main concerns are feasibility and performance, or if there is just a way to do it better. I have not implemented this, so ideas that sound good on paper can definitely go wrong during implementation.
 
If I were to use Microsoft's Thread Pool API, the code would not be portable. Also, I would be missing out on the learning process and skill building of creating my own threading algorithm and dealing with these kinds of issues. What's the fun in simply learning another API and using it?

Edit: And just looking at my diagram again a couple of times, the arrow from the worker thread that says Dequeue() should be pointing at the Work Queue, not at the Work Unit, however, it would receiver a work unit to work with on dequeuing from the Work Queue.
 
The Windows thread pool is useful, but has a rather limiting design.

_beginthreadex() isn't portable, neither are the rest of the primitives when you'll be using when synchronizing work between the threads.

I'm not sure I quite understand your drawing. It implies that your thread pool will create a thread to do some work, each time. The point of a thread pool is to keep the threads around, blocking, until they do have work to do. Deciding when to create or destroy a thread is an interesting tuning point, and one of the important factors you can't influence when using the Windows thread pool.

That there are two arrows coming out of the "Thread pool" box is also confusing. When does a DoWork() call result in a QueueWork() action, and when does it result in a _Beginthreadex() action?
 
Sorry, I apologize for the diagram, as the arrows don't particularly mean anything per se. They just link components together in an abstract fashion. Let me explain:

The Threadpool will create threads that do not return and they will initially be sleeping. These threads will be signaled when there is work in the work queue, and as a result, they will wake up, dequeue an item, process it, and hand it back to the pool as a result, check the pool again, and if there is nothing else, go back to sleep until re-signaled.

As for the arrows coming out of the Threadpool, DoWork() always results in a QueueWork() action, but the _beginthreadex() are called on initialization of the thread pool, so basically, the threads will be there by the time any DoWork() calls are made.
 
That's a sensible approach, then. You'll want to have a way to govern the length of the queues, and make sure that you have a sensible number of threads. Depending on the characteristics of the work load, you might want to find a way to start with one or a few threads, then spin up more as workload demands, and perhaps kill them as workload diminishes.

Other'n that, I'd go for it.
 
mikeblas said:
That's a sensible approach, then. You'll want to have a way to govern the length of the queues, and make sure that you have a sensible number of threads. Depending on the characteristics of the work load, you might want to find a way to start with one or a few threads, then spin up more as workload demands, and perhaps kill them as workload diminishes.

Other'n that, I'd go for it.
Click to expand...

Those seem like good ideas. I was initially thinking of putting the burden of queue lengths on the programmer (don't pass a piece of work that is too long), but I will give this issue some thought.

Thanks.
 
You must log in or register to reply here.
Back
Top