KMThreadPool: 3 – Thread Pool Step 1: Utilities, Locks and Algorithms

3 – Thread Pool Step 1:Utilities, Locks and Algorithms

Utilities:

We’re going to set up some classes and type definitions for use through-out the thread pool. These will be our utility objects, stored in thekmp::threading::utility namespace. For this project, we only have 2 objects in our Utility namespace: a function pointer type defined as KMTaskFunc and an abstractbase class entitled IKMTaskData. Lets have a look:

namespace utility

{

         //Class Interfaces

         class IKMTaskData

         {

         public:

                  IKMTaskData() {}

                  IKMTaskData(const IKMTaskData&) {}

                  IKMTaskData& operator = (const IKMTaskData&) {}

                  virtual ~IKMTaskData() = 0 {};

         };

         //Type Definitions

         typedef void (*KMTaskFunc)(IKMTaskData*);

}

These 2 objects are actually the heart of the thread pool, believe it or not (if you don’t: OK, fine, enjoy your busted thread pool). Here is an overview on how theKMTaskFunc and IKMTaskData work inside the thread pool.

KMTaskFunc

This function pointer is going tobe the task we want to put on another thread. You can define this functionanywhere inside your program* – the thread pool itself will beset up to accept a function pointer to send to the threads.

The task function pointer we’veset up here is returning void. You could have it return another value, but youwould need to set up a way to get that value back from the threads, which ispretty tedious, so we’ll stick to the basics. The only parameter is a pointerto the ABC IKMTaskData.

IKMTaskData

A problem with threading is thepassing of data, especially shared data. Because of paralellism, threads thatshare a variable could modify it or access it at the same time (as I’ve said onpage 2). A method around this is to give the thread classes local storage ofthe data they need to complete the task, filled out with data from the exactmoment they were created that won’t be modified by other threads (meaning:avoid using pointers).

To do this effectively, we haveour IKMTaskData. When you’re developing you tasks, you’ll create child classes the derivefrom this ABC, Adding in members and such that your task will need, to passalong to the threads. When sending this task to the thread pool, the pool willcast your class to the IKMTaskData. Inside or your task, you’ll cast it back to yourchild object, and grab all the yummy data goodness you loaded into it. Simple.

* Note: If your task function pointer is a member function inside a class, it won’twork; the function must be static in order to work correctly. A method aroundthis is to create a static member function in your class, and in your childIKMTaskData class, have a pointer to this. Inside that static function, youwould call the task you wanted to multithread.

Example:

First, create the task child object, addingwhatever members you’ll need.

class taskData : IKMTaskData

{

 public:

 A* ptr_A;

 int _a;

 int _b;

 ...

 ...

}

Define our class, with the task that gets calledby the thread, and the task that does the actual work.

class A

{

 void task(int a, int b)

 {

  //Do Stuff...

 }

 static void STATIC_TASK(IKMTaskData* data)

 {

  taskData* myData = (taskData*)data;

  A* myClass = myData->ptr_A;

  myClass->task(myData->_a, myData->_b);

 }

 ...

 ...

}

Then, somewhere inside of class A…

...

...

pthreadpool->AddTask(STATIC_TASK, new taskData(this, 100, 6));

...

...

Locking

KMLock

Locking is one of the morepowerful tools we have when developing multithreaded applications, but it’s alsoa double-edged sword when abused. Locking, in terms of threading, preventsother threads from running a segment of code while it’s “locked” and will blockall other threads until the segment is Unlocked. That’s very helpful if youhave sensitive data that should only be modified by one thread at a time…

But it can slow you down. How?Think about it: you’re blocking the other threads from processing code(assuming other threads want to process the same code all at once). You createa bottle neck. However, if you keep the segment small enough, and don’t uselocks like a madman, you’ll be fine. In the event that you make a game to thescale of Crysisor World of Warcraft, and you’re locking so muchyour game is moving at 6 FPS, then you may want to consider looking intolockless algorithms (and, I warn you, locklessness is a pain).

So here’s a glimpse at the KMLock class we use in the thread pool.

class KMLock

{

private:

         CRITICAL_SECTION m_critsec;

public:

         KMLock()

         {

                  ::InitializeCriticalSection(&m_critsec);

         }

         ~KMLock()

         {

                  ::DeleteCriticalSection(&m_critsec);

         }

         void Lock()

         {

                  ::EnterCriticalSection(&m_critsec);

         }

         void Unlock()

         {

                  ::LeaveCriticalSection(&m_critsec);

         }

protected:

};

For the locks, we’re just usingWindows Critical Sections (maybe one day I’ll change it touse a more cross-platform implemntation, but for now that is fine). Use thisclass wisely and sparingly; don’t lock what doesn’t need to be.

Algorithms

KMQueue

To make this simple: *SPOILERALERT!* our Thread Pool class is going to contain a task queue. Once one ourthreads goes idle, it will check the task queue, and pop off the next task andrun it. That’s how the heart beats in our thread pool (unless you’re the guywho chose to be the “nonbeliever” earlier).

So why did I make a queue? I usedCritical Sections earlier, and Windows has the STD library!

Let me tell you something: thecurrent C++ STD library isn’t thread-safe (but the STD library coming in C++0xis); there’s no locking, nocompare-and-swaps – nothing.That’s why I’ve researched what’s called aTwo-LockQueue by Maged M. Michael and MichaelL. Scott. You can find the PDF they wrote on it here for more information->1996PODC Queues. I’m going to just run down the quick-and-dirty basics withyou.

Our problem here is we’ll have atime when one thread will try modifying the queue while another thread is.They’ll run into problems like trying to delete data while another thread isaccessing it, or theABA problem. Our simplistic solution requires just 2locks and a false head.

Our queue is comprised of nodes.The nodes are simple: a templated TYPE for the item in the node, and a nextpointer. Our queue has 4 members: a head node pointer, a tail node pointer, aKMLock for the head, and a KMLock for the tail.

In the constructor, we create ourfirst node. Why? This node is going to be a dummy node. A problem occurs when 2threads try to access the same data. One thread can delete the data while theother thread thinks the data is still valid. The other thread tries to use thedeleted data and BAM! Zombie thread. So what we do is we use the head pointeras an “invalidation data container.” When we callpop() on the queue, instead of popping off thehead and returning the data from the head, we get the data from the heads’next, then pop the head and move the heads next into the head position.Confusing, but by doing this, we allow for the possiblity for 2 threads to tryto access the head. So if one thread gets the head while another is accessingit, the head in the queue is moved to an invalidation container instead ofgetting totally deleted, so both values are still valid. The heads get deletedon the next pop. (If you still don’t get it (and I don’t blame you) read thewhitepaper a few times and look at the code. You’ll facepalm once you get it).

The locks are simple tounderstand in their logic. They’re just there so one thread can be pushingwhile another thread is popping. both provide protection to their specifiednodes so no 2 threads can try topush() or pop() at the same time.

Then there’s the empty() function, which checks if the queue isempty. if the head node has a next, the queue is not empty. If it’s just thehead, then it is (remember, the head is just an invalid dummy). This is themost exciting function in the whole project. Not.

 

转自：http://keithmaggio.wordpress.com/code/c-win32-thread-pool-manager/3-step1/