使用OpenMP编程时，通常都是将函数内的某段代码并行化执行，但是，对于在函数内声明的变量，很容易被多个线程同时读写访问，这将导致数据竞争问题。

不妨先看一个代码例子：

找出下面代码中的问题

template <class T>

void Parallel_Matrix_Sub(T *a, int row_a, int col_a, int as,  T *b, int bs, T *c, int cs)

{

int i, j;

int nCore = omp_get_num_procs();

#pragma omp parallel for num_threads(nCore)

for ( i = 0; i < row_a; i++ )

{

int row_i_a = i * as;

int row_i_b = i * bs;

int row_i_c = i * cs;

for ( j = 0; j < col_a; j++ )

{

//c[i][j] = a[i][j] - b[i][j]

c[row_i_c + j] = a[row_i_a + j] - b[row_i_b + j];

}

}

}

稍有经验的人就可以发现，上面代码中，j变量声明在OpenMP语句块的外面，因此，对各个线程来说，它是共享变量，OpenMP创建的多个线程都会访问j。内层循环中的j++可能会被多个线程同时执行，将导致程序运行出现无法预测的错误。改正后的代码如下：

template <class T>

void Parallel_Matrix_Sub(T *a, int row_a, int col_a, int as,  T *b, int bs, T *c, int cs)

{

int i;

const int nCore = omp_get_num_procs();

#pragma omp parallel for num_threads(nCore)

for ( i = 0; i < row_a; i++ )

{

int   j;

int row_i_a = i * as;

int row_i_b = i * bs;

int row_i_c = i * cs;

for ( j = 0; j < col_a; j++ )

{

//c[i][j] = a[i][j] - b[i][j]

c[row_i_c + j] = a[row_i_a + j] - b[row_i_b + j];

}

}

}

注意上面的代码中的加粗两行，变量j改为在内层循环内声明，这样创建线程时，变量j为每个线程的局部变量，不存在数据竞争问题。

对于const int nCore = omp_get_num_procs(); 这行，将变量nCore声明为

const类型后，后面的代码就无法对其进行写操作，可以避免线程内的代码对线程外的变量进行写操作，避免数据竞争问题。

根据上面的实例修改情况，可以归纳出两条避免OpenMP出现数据竞争的建议：

1．  尽量在并行循环内部申明局部变量

2．  对于并行循环外面的变量，尽量使用const类型，以保证在并行循环内不会发生写操作。对于没有使用const的变量，表明需要进行写操作，可以在检视代码时重点检视这些未使用const的变量是否用了锁或原子操作来进行保护。

参考材料： OpenMP编程指南

注：本文主要根据今年到某企业讲课的胶片整理而成，因为是胶片，内容会显得比较精简，不到之处还请海涵。

多核程序的调试与测试历来是世界性难题，岂止为止没有发现能够对付它的银弹。这是因为多核程序与单核程序有着很大的不同，单核程序通常是一些内存访问、资源泄漏、计算错误（如差1）等。多核程序中，不仅会遇到单核程序中所遇到的所有问题，还会遇到许多新的问题和陷阱。

多核程序常见问题与陷阱

多核常见问题和陷阱如下：

1）数据竞争

2）死锁

3）数据操作时序

4）活锁

5）原子操作

6）资源回收

7）优先级翻转

8）线程挂起或死亡

9）线程重启

下面就来探讨一下这些问题和陷阱

数据竞争

常见的数据竞争问题有以下几种：

1）OpenMP中的数据竞争

2）原子操作中的数据竞争

3）通常多线程环境中的数据竞争

一般来说，数据竞争是一种非常难以发现和调试的问题，因为多个线程同时操作某个变量的频率本来就非常低，这使得问题需要重复非常多次才能出现一次，给测试带来了难度。

同时，如果要对数据竞争问题进行定位，难度就更大了，如果进行单步执行，问题很可能根本就不会出现。

对付数据竞争最有效的方法就是使用人工进行代码静态审查，找一些对多线程编程富有经验的人，对含有共享数据操作的模块进行代码检视。

另外一个方法就是借助工具，有一些专门的工具可以用来检查某些类型的数据竞争问题，比如Intel线程检测器工具可以识别数据竞争、死锁、等问题。

测试方法和步骤

1）先将程序编译成串行版本

2）对串行版本进行详尽的测试，确保没有问题

3）再编译成并行版本

4）对并行版本进行测试

死锁测试

死锁问题一般可以通过设计消除

– 将Lock() Unlock()操作改成 CScopedLock类调用

–  避免嵌套锁

– 检查是否有活锁问题

– 采用类似内存测试的方法进行测试

数据竞争测试

在核数较多的机器上进行测试

代码中不要插入测试和调试代码

如果用了sleep等延时操作，可以将其注释掉进行测试

代码静态检查

人工进行代码静态检查是必须的

重点检查数据竞争和数据操作时序

测试用例设计

基于阻塞情况而设计用例

– 比如在数据为空或为满情况下是否会出现阻塞现象

基于数据状态而设计用例

– 比如设计一些可能出现的中间数据状态，作为输入进行测试

测试用例设计

设计模拟线程切换的用例

– 监控共享变量的读写

– 让一个线程进行上锁状态然后挂起，其他线程继续运行，看是否会操作到共享变量

问题定位

在实践中发现，如果采用单元测试进行问题定位，效果通常较好，所以一定要做单元测试啊！采用其他手段定位则麻烦许多，其他常见的定位手段如下：

1）采用数据断点进行定位

2）分段调试进行定位

3）暴力调试进行定位

顺便说一下，对于多线程调试与测试，通常需要较好的工具来支持，对于某些用工具几分钟就能解决的问题，不使用工具或许会需要几天甚至被卡住而做不下去。

导致死锁的因素通常有以下几种：

1）忘记解锁

2）嵌套锁顺序错误

3）递归锁

死锁的问题很容易解决，忘记死锁可以通过使用CScopedLock类，利用类的析构函数自动释放锁，程序中尽量避免使用嵌套锁等，一般来说，嵌套锁都可以改写成非嵌套的锁。

数据操作时序

数据操作时序和数据竞争不一样，它发生于两次加锁解锁之间进行了任务切换。如果第2次加锁解锁的共享变量依赖于第1次加锁解锁的共享变量，两次之间切换任务时，修改了第1次的共享变量的值，将导致第2次访问的共享变量的值的变化，从而产生一些不可预知的问题。

数据操作时序问题的出现是随机性的，有些问题出现概率很小，很难定位

一般使用代码静态分析方法来发现这类问题

使用原子操作时最容易犯这个问题，这也是无锁编程的困难所在

活锁

多个线程A、B、C都在等待某一个锁，线程A释放锁，线程B获得锁，这时线程A又重新等待锁，线程B释放后，线程A又获得锁，如此循环下去，将导致线程C永远得不到锁。

这种锁一直被某几个线程持有，使得某个线程一直等不到锁的情况叫做“活锁”。

活锁问题通常与操作系统的线程调度策略有关，对于现代操作系统来说，同优先级线程通常采用轮循调度，一般不会发生活锁问题，但是对于不同优先级的线程，通常采用抢占式调度，则有可能发生活锁问题。

原子操作

现在的多核机器通常都支持原子操作，原子操作通常比锁的效率高（注：也有用原子操作实现的锁），原子操作一个最大的优势就是不会出现死锁，另外使用原子操作操作的变量，读取该变量时和读取普通变量是一样的，即使锁做得和原子操作一样快，原子操作也可以省去一半的操作开销。

原子操作使用的难度要比锁高，因此有以下注意事项：

1）原子操作极易引起数据竞争和数据操作时序问题

2）通过返回值获取变量修改后的值

3）不要轻易对指针使用原子操作

资源回收

多线程环境中的资源回收和单线程环境不同，单线程环境的回收资源通常是指资源泄漏问题，多线程环境的资源回收是指在回收了某个资源后，还有一些没有退出的常驻线程会继续访问这些已被释放了的资源。

保证安全回收资源的两点建议：

1）  确保资源回收前，其他线程都不会再访问这个资源

2）使用多线程退出算法来保证资源被回收前，让需要访问这个资源的线程全部退出。

线程挂起或死亡

在使用了锁的线程中，线程挂起通常是非常危险的问题，因为它有可能导致线程持有的锁没有释放，从而让其他线程等不到锁，一直等待下去。

线程重启

有些应用中，需要在不退出进程的情况下将线程重启，将线程重启也是一种难度较高的动作，因为首先需要将原线程退出，再将线程运行起来，线程重启时，如何确保资源被安全释放或安全保存，如何保证重启时，程序数据的安全？对于大型软件来说，这些问题都是比较棘手的问题。因此，除非有特殊需要，一般不要设计线程可以重启的应用。

要做到让线程重启的安全，以下几点供参考：

1）使用多线程退出算法让线程自然退出

2）释放线程私有资源

3）释放线程持有的锁

至此，将多线程编程常见问题和陷阱简要地过了一遍，下面接着谈谈多核程序测试方面。

/*

 * Copyright (c) 2006-2008

 * Author: Weiming Zhou

 *

 * Permission to use, copy, modify, distribute and sell this software

 * and its documentation for any purpose is hereby granted without fee,

 * provided that the above copyright notice appear in all copies and

 * that both that copyright notice and this permission notice appear

 * in supporting documentation. 

 */

#ifdef _WIN32

#define _WIN32_WINNT 0x0401

#include <windows.h>

#else

#include <pthread.h>

#endif

#include "CapiGlobal.h"

#include "CThreadPool.h"

#include "CLocalQueue.h"

#include "CStealQueue.h"

#include "CDistributedQueue.h"

#include "CWaitTaskScheduler.h"

static unsigned int WINAPI WaitTaskScheduler_StartFunc(void *pArgs);

#define     WAITTASK_QUEUE_SIZE     128

CWaitTask::CWaitTask()

{

    pCount = NULL;

}

CTaskArray::CTaskArray(int nTaskArraySize)

{

    m_nTaskArraySize = nTaskArraySize;

    m_lTaskCount = 0;

    m_lCurTaskCount = 0;

    m_pTaskArray = new CWaitTask[nTaskArraySize];

    INT i;

    for ( i = 0; i < nTaskArraySize; i++ )

    {

        m_pTaskArray[i].pCount = &m_lCurTaskCount;

    }

}

CTaskArray::~CTaskArray()

{

    delete [] m_pTaskArray;

}

INT CTaskArray::AddTask(THREADFUNC func, void *pArg)

{

    if ( m_lTaskCount >= m_nTaskArraySize )

    {

        return CAPI_FAILED;

    }

    m_pTaskArray[m_lTaskCount].func = func;

    m_pTaskArray[m_lTaskCount].pArg = pArg;

    m_lTaskCount += 1;

    m_lCurTaskCount = m_lTaskCount;

    return CAPI_SUCCESS;

}

LONG CTaskArray::GetTaskCount()

{

    return m_lTaskCount;

}

LONG CTaskArray::GetCurTaskCount()

{

    return m_lCurTaskCount;

}

/**   等待任务调度的构造函数

         @return  constructor - 无     

*/

CWaitTaskScheduler::CWaitTaskScheduler()

{

    m_StartFunc = WaitTaskScheduler_StartFunc;

    int n = m_ThreadPool.GetThreadCount();

    m_DQueue.Create(WAITTASK_QUEUE_SIZE, n, WAITTASK_QUEUE_SIZE, 0,

        ThreadPool_GetThreadId, &m_ThreadPool);

}

/**   等待任务调度的设置线程池的入口函数

         @param  THREADFUNC StartFunc - 线程池的入口函数     

         @return  void - 无 

*/

void CWaitTaskScheduler::SetStartFunc(THREADFUNC StartFunc)

{

    m_StartFunc = StartFunc;

}

/**   等待任务调度的获取任务函数

         @param  TASK &Task - 接收从分布式队列中获取的任务

         @return  int - 成功返回CAPI_SUCCESS, 失败返回CAPI_FAILED.    

*/

int CWaitTaskScheduler::GetTask(CWaitTask &Task)

{

    //先从本地队列获取任务

    //本地获取任务失败后从共享队列获取任务

    return m_DQueue.DeQueue(Task);

};

/**   等待任务调度的获取线程池函数

    @return  CThreadPool & - 返回线程池对象        

*/

CThreadPool & CWaitTaskScheduler::GetThreadPool()

{

    return m_ThreadPool;

}

/**   等待任务调度的原子增加任务Id函数

    @return  int - 返回原子加后的任务Id.       

*/

LONG CWaitTaskScheduler::AtomicIncrementTaskId()

{

    LONG Id = AtomicIncrement(&m_lTaskId);

    return Id;

}

/**   等待任务调度的生成当前线程的本地任务

    任务被放入当前线程的本地队列中

         @param  TASK &Task - 待执行的任务

         @return  void - 无 

*/

void CWaitTaskScheduler::SpawnLocalTask(CWaitTask &Task)

{

    //将任务放入本地队列中

    m_DQueue.PushToLocalQueue(Task);

};

/**   等待任务调度的生成任务函数

    生成的任务被放入分布式队列中

         @param  TASK &Task - 待执行的任务

         @return  void - 无 

*/

void CWaitTaskScheduler::SpawnTask(CWaitTask &Task)

{

    if ( m_lTaskId < m_ThreadPool.GetThreadCount() )

    {

        //依次唤醒各个挂起的线程

        LONG Id = AtomicIncrement(&m_lTaskId);

        if ( Id < m_ThreadPool.GetThreadCount() )

        {

            //下面之所以可以对其他线程的本地队列进行无同步的操作，是因为

            // 访问这些队列的线程在进队操作之后才开始运行

            m_DQueue.PushToLocalQueue(Task, Id);

            m_ThreadPool.ExecThread(Id);

        }

        else

        {

            m_DQueue.EnQueue(Task);

        }

    }

    else

    {

        //先判断共享队列是否满，如果未满则放入共享队列中

        //如果满了则放入本地队列中

        m_DQueue.EnQueue(Task);

    }

};

/**   等待任务调度的启动根线程函数

         @param  TASK &Task - 要执行的最初任务

         @return  void - 无 

*/

void CWaitTaskScheduler::BeginRootThread(CWaitTask &Task)

{

    m_lTaskId = 0;

    m_ThreadPool.CreateThreadPool(m_StartFunc, this, 0);

    m_DQueue.PushToLocalQueue(Task, 0);

    m_ThreadPool.ExecThread( 0 ); 

    m_ThreadPool.WaitAllThread();

}

/**   等待任务调度的线程池入口函数

         @param  void *pArgs - CWaitTaskScheduler类型的参数    

         @return  unsigned int WINAPI - 返回  

*/

static unsigned int WINAPI WaitTaskScheduler_StartFunc(void *pArgs)

{

    CWaitTaskScheduler  *pSched = (CWaitTaskScheduler *)pArgs;

    CWaitTask    Task;

    int     nRet;

    for ( ;; )

    {

        nRet = pSched->GetTask(Task);

        if ( nRet == CAPI_FAILED )

        {

            CThreadPool &ThreadPool = pSched->GetThreadPool();

            // 唤醒一个挂起的线程,防止任务数量小于CPU核数时，

            // 仍然有任务处于挂起状态,从而导致WaitAllThread()处于死等状态

            // 这个唤醒过程是一个串行的过程，被唤醒的任务会继续唤醒一个挂起线程

            LONG Id = pSched->AtomicIncrementTaskId();

            if ( Id < ThreadPool.GetThreadCount() )

            {

                ThreadPool.ExecThread(Id);

            }

            break;

        }

        (*(Task.func))(Task.pArg);

        if ( Task.pCount != NULL )

        {

            AtomicDecrement(Task.pCount);

        }

    }

    return 0;

}

void CWaitTaskScheduler::SpawnTaskArrayAndWait(CTaskArray *pTaskArray)

{

    int i;

    for (i = 0; i < pTaskArray->GetTaskCount(); i++ )

    {

        SpawnTask(pTaskArray->m_pTaskArray[i]);

    }

    // 等待上面的任务列表全部执行完成

    while ( pTaskArray->GetCurTaskCount() != 0 )

    {

        //切换到其他任务上执行，即偷取其他任务来执行

        CWaitTask task;

        int nRet = GetTask(task); //从分布式队列中偷取任务

        if ( nRet == CAPI_FAILED )

        {

            CAPI_Yield(); //将当前线程暂时切换到后台

        }

        else

        {

            (*(task.func))(task.pArg); //执行偷取到的任务

            if ( task.pCount != NULL )

            {

                AtomicDecrement(task.pCount); //将任务计数减

            }

        }

    }

    //pTaskArray->GetCurTaskCount()返回表示所有需要等待的任务都执行完成

    //此时可以退出等待了

    return;

}

由于有依赖关系的调度其他部分和前面列出的几篇文中中讲的动态任务调度类似，因此就不再详述了，下面列出它的完整代码。

// 下面是CWaitTaskScheduler.h头文件内容

class CWaitTask {

public:

    THREADFUNC      func;         //任务执行函数

    void            *pArg;        //任务函数的参数

    volatile LONG   *pCount;      //任务组计数指针，为等待一组任务执行完而设计

    CWaitTask();

};

class CTaskArray {

public:

    CWaitTask   *  m_pTaskArray;

    int            m_nTaskArraySize;

    LONG         m_lTaskCount;

    volatile LONG   m_lCurTaskCount; //任务组中任务个数计数，

                                 //可以用来为等待一组任务执行完进行判断

    CTaskArray(int nTaskArraySize);

    ~CTaskArray();

    INT AddTask(THREADFUNC func, void *pArg);

    LONG GetTaskCount();

    LONG GetCurTaskCount();

};

class CWaitTaskScheduler {

private:

    CThreadPool     m_ThreadPool;//(TaskScheduler_StartFunc, NULL, 0);

    CDistributedQueue<CWaitTask, CLocalQueue<CWaitTask>,   

    CStealQueue<CWaitTask>> m_DQueue;

    THREADFUNC      m_StartFunc;  //为线程池使用的线程入口函数指针

    LONG  volatile  m_lTaskId;    //Task Id,用于判断是否唤醒对应的线程

public:

    CWaitTaskScheduler();

    //下面三个函数为调度器的使用者使用

    void SpawnLocalTask(CWaitTask &Task);

    void SpawnTask(CWaitTask &Task);

    void SpawnTaskArrayAndWait(CTaskArray *pTaskArray);

    void BeginRootThread(CWaitTask &Task);

};

当任务计数不为0时，必须等待其他任务完成，在通常的做法中，都是要用一个栅障来进行等待，实际上，判断计数不为0时，线程可以不进行等待，去偷取其他线程的任务执行，这样线程就不用空等，同时因为在执行其他线程的任务，也不会往下执行，保证了任务的执行时序和依赖关系。

         下面给出关键部分的实现代码：

 void CWaitTaskScheduler::SpawnTaskArrayAndWait(CTaskArray *pTaskArray)

{

    int i;

    for (i = 0; i < pTaskArray->GetTaskCount(); i++ )

                   SpawnTask(pTaskArray->m_pTaskArray[i]);

// 等待上面的任务列表全部执行完成

while ( pTaskArray->GetCurTaskCount() != 0 )    

 {

//切换到其他任务上执行，即偷取其他任务来执行

        CWaitTask task;

        int nRet = GetTask( task );  //从分布式队列中偷取任务

        if ( nRet == CAPI_FAILED )

            CAPI_Yield();  //将当前线程暂时切换到后台

        else  

 {

            (*(task.func))( task.pArg );  //执行偷取到的任务

            if ( task.pCount != NULL )

                  AtomicDecrement( task.pCount ); //将任务计数减1

        }

    }

    //GetCurTaskCount()返回0表示所有需要等待的任务都执行完成, 此时可以退出等待了

    return;

}

上面的SpawnTaskArrayAndWait()函数中，先生成一组任务，然后用一个while循环来等待生成的一组任务全部执行完，可以看到在while循环中，只有当偷取任务失败时，才会调用CAPI_Yield()函数将线程切换到后台，其他时候一直都是处于执行状态的，没有调用任何真正意义的等待函数（如Windows系统中的WaitForSingleObject）来进行等待，寥寥数行代码就将一个有依赖关系的动态任务调度的最核心部分给实现了。

从上图可以看出这种分块相乘总共用了8次乘法，当然对于子矩阵相乘（如A0×B0），还可以继续递归使用分块相乘。对于中小矩阵来说，很适合使用这种分块乘法，但是对于大矩阵来说，递归的次数较多，如果能减少每次分块乘法的次数，那么性能将可以得到很好的提高。

Strassen矩阵乘法就是采用了一个简单的运算技巧，将上面的8次矩阵相乘变成了7次乘法，看别小看这减少的1次乘法，因为每递归1次，性能就提高了1/8，比如对于1024*1024的矩阵，第1次先分解成7次512*512的矩阵相乘，对于512*512的矩阵，又可以继续递归分解成256*256的矩阵相乘，…，一直递归下去，假设分解到64*64的矩阵大小后就不再递归，那么所花的时间将是分块矩阵乘法的(7/8) * (7/8) * (7/8) * (7/8) = 0.586倍，提高了快接近一倍。当然这是理论上的值，因为实际上strassen乘法增加了其他运算开销，实际性能会略低一点。

下面就是Strassen矩阵乘法的实现方法，

    M1 = (A0 + A3) × (B0 + B3)

    M2 = (A2 + A3) × B0

    M3 = A0 × (B1 - B3)

    M4 = A3 × (B2 - B0)

    M5 = (A0 + A1) × B3

    M6 = (A2 - A0) × (B0 + B1)

    M7 = (A1 - A3) × (B2 + B3)

    C0 = M1 + M4 - M5 + M7

    C1 = M3 + M5

    C2 = M2 + M4

    C3 = M1 - M2 + M3 + M6

在求解M1,M2,M3,M4,M5,M6,M7时需要使用7次矩阵乘法，其他都是矩阵加法和减法。

下面看看Strassen矩阵乘法的串行实现伪代码：

Serial_StrassenMultiply(A, B, C) 

{

    T1 = A0 + A3;

    T2 = B0 + B3;

    StrassenMultiply(T1, T2, M1);

    T1 = A2 + A3;

    StrassenMultiply(T1, B0, M2);

    T1 = (B1 - B3);

    StrassenMultiply (A0, T1, M3);

    T1 = B2 - B0;

    StrassenMultiply(A3, T1, M4);

    T1 = A0 + A1;

    StrassenMultiply(T1, B3, M5);       

    T1 = A2 – A0;

    T2 = B0 + B1;

    StrassenMultiply(T1, T2, M6);

    T1 = A1 – A3;

    T2 = B2 + B3;

    StrassenMultiply(T1, T2, M7);

    C0 = M1 + M4 - M5 + M7

    C1 = M3 + M5

    C2 = M2 + M4

    C3 = M1 - M2 + M3 + M6

}

下面给出动态任务调度实现Strassen矩阵相乘的伪代码。

Parallel_StrassenMultiply(A, B, C) 

{

    T1 = A0 + A3;

    T2 = B0 + B3;

    SpawnTaks(M1 = T1* T2);

    T1 = A2 + A3;

    SpawnTask(M2 = T1* B0);

    T1 = (B1 - B3);

    SpawnTask (M3 = A0 * T1);

    T1 = B2 - B0;

    SpawnTask(M4 = A3 * T1);

    T1 = A0 + A1;

    StrassenMultiply(M5 = T1 * B3);       

    T1 = A2 – A0;

    T2 = B0 + B1;

    SpawnTask(M6 = T1 * T2);

    T1 = A1 – A3;

    T2 = B2 + B3;

StrassenMultiply(M7 = T1 * T2);

Wait 上面7个任务完成

    C0 = M1 + M4 - M5 + M7

    C1 = M3 + M5

    C2 = M2 + M4

    C3 = M1 - M2 + M3 + M6

}

要实现上面伪代码中的等待7个任务完成的功能是非常简单的，只要实现一个栅障(barrier)一样的功能就可以了，不过简单地使用栅障功能会带来许多副作用，因为它可能会使某些线程陷入等待的空闲状态，我们必须做到某个线程对应的7个任务未完成时，它不能空等，而需要去偷取属于其他线程的任务来执行，这样才能保证所有的线程都处于忙状态，使得CPU核得到充分利用。

所以，我们的有依赖关系的任务调度不会使用简单的栅障来实现任务等待，而会采用更高效的方式来实现等待功能，最高效的等待方式是什么？最高效的等待方式就是“不等待”。有没有搞错啊？不是说要实现等待功能吗，怎么能用“不等待”来实现等待呢？

或许有人看到这里要头晕了，其实我自己也头都晕了，因为实在找不到好的方式来解释用“不等待”实现等待的问题，只好把老子的道德经里的“有中生无，无中生有”搬出来一下，简单地说就是用“不等待”来生成“等待”。

闲话少叙，还是看看具体的实现思想。

多核中的动态任务调度算法可以说是多核三大算法之首，因为它可以将一些串行程序变成并行执行的。程序员只要按照一定接口规范写串行算法，就可以用动态任务调度器将其并行运行。Intel TBB库中就实现了一个动态任务调度算法，不过TBB库中的实现代码量较大（大约有4000多行代码），估计没有多少人能完全看得明白，我在开源MCAPI(原CAPI项目，迁移到Sourceforge后改名为MCAPI)库(地址：http://sourceforge.net/projects/mcapi)中也实现了几种不同类型的动态任务调度算法，这些实现中的任何一种都只用了两百行代码左右，其中有部分实现方法在今年5~6月份时已撰文介绍了，文章链接如下：

多核中的动态任务调度(1)

多核中的动态任务调度(2)

多核中的动态任务调度(3)

多核中的动态任务调度(4)

用动态任务调度器实现Parallel_For （1）

用动态任务调度器实现Parallel_For （2）

用Parallel_For进行并行快速排序

用Parallel_For进行并行快速排序

用Parallel_For进行并行快速排序

上面这些文章中介绍的动态任务调度算法，也能实现将一些串行算法自动变成并行执行，不过这个算法的功能相比TBB中的动态任务调度算法功能上要差一些，因为它只能实现一些简单的无依赖关系的动态任务调度，当任务间存在依赖关系时，必须等待依赖的任务完成后，才能继续执行下面的任务。为了弥补上述动态任务调度功能上的不足，我在今年年初时设计了一个新的动态任务调度算法，可以实现有依赖关系的动态任务调度。

下面就是一种典型的有依赖关系的任务调度

l  将一个大的任务被拆分成多个小任务

l  需要等这多个小任务全部处理完，然后才能对多个小任务处理结果进行合并

l  拆分任务和对任务结果进行合并间需要进行等待

为了进一步说明问题，下面以并行Strassen矩阵乘法来说明这种有依赖关系的任务调度问题。