5G基站基带架构之Ping-pong架构

一般的，作为一个实时操作系统，要求该系统能实时处理响应，对于是单线程的系统而言，如果这个线性在处理业务的时候，就意味着，外界发送的消息等事件，只能等到CPU不在处理业务的时候，才能响应。
代码框架如下

main()
{
  while (loop)
  {
    receive message;
    switch(MSGID);
    {
      case CONFIG_REQ:
        thing 1;
        break;
      case RUN_REQ:
        thing 2;
        break;
      case STOP_REQ:
        thing3;
	    break;
      default:
	    something;
    }
  }
}

该程序，假如thing 2需要大量的cpu cycle才能处理结束，那么意味着，在这个期间，该系统是无法处理外界消息的，只能把消息存储起来，等thing 2结束，才能对外界的响应予以行为，这显然，无法应对通信的系统要求。

于是，为了实时性，就需要两个线程A，B。当有两个线程的时候，就需要考虑一下线程内任务项的balance。经过沉淀，ping-pong机制应运而生，模型如下

mian1()
{
  while(loop)
  {
    receive message;
    switch(MSGID)
    {
      case MSG1:
        thing 1;
        break;
      case MSG2:
        thing 2;
        break;
      case MSG3:
        thing 3;
        break;
      default:
        something;
    }
  }
}
main2()
{
  while(loop)
  {
    receive message;
    switch(MSGID)
    {
      case MSG1;
        thing 4;
        break;
      case MSG5;
        thing 5;
        break;
      case MSG6:
        thing 6;
        break;
      default:
        something;
    }
  }
}

该程序，总的来说，两个线程的load大体相当，具体到每个线程来讲，可以简单假设为thing2和thing5是需要大量运算的事件，那么，在thing2做完之后，由thing2发送一个中断到main2，来触发thing5，当thing5在做完之后，由thing5发送一个中断到mian1，来触发thing2。其他消息，对于main1来说，则是在运行thing2之外的其他时间处理，对于main2来说，则是在运行thing5之外的其他时间处理。

这种系统架构，对内存来说，用ping-pong buffer的机制，可以说是锦上添花。简单来说，由于thing2和thing5是该系统的主要任务，当main1 的thing 2运行之后后，其存储结果的内存在随着中断指示的发送，一并给main2，并由thing 5来handle，等到thing 5 运行之后，同样把存储结果的内存随着中断指示的发送，一并给main1，并由thing2来handle，如此往复，周而复始。

对于上述运行和存储机制，一般会由所改变，比如只是单向的main 1给mian 2发中断，main 1的thing2由timer来启动。需要指出的是，在通信基站中，线程或者说task的启动，timer占有很重要的分量。

这种系统架构，对于CPU/DSP等计算单元来说，不要求很多的核心，但是需要主频较高，一般的，由于每个核心的主频一样或者差不多，所以，正如前文所说，在两个软件线程的load设计上，需要尽量平均。该系统，基本适用于市面上常用的DSP，CPU等计算单元。不过主频高，意味着耗电，一般的，频率与电压成正比，电压的平方与功率成正比，所以，如果频率降低，那么功耗的减小非常可观，具体的数据，大家可以参考NVIDIA的max Q系列显卡，其介绍说明等技术数据很详实。

这种系统架构，对于开发人员来讲，比较简单，便于理清业务模型，尤其对于变量作用时间的把握，也比较简单。

但是，该系统在一次次做增量开发之后，就会遇到两个线程load越来越不平衡，甚至外界消息都来不及处理的问题，至于该问题该如何解决，这是需要该设计者，能够不忘初心，作为该产品的守护者，甚至重新评估事件，并重新balance系统，这里就不大篇幅讨论了。

仅表述这么多，欢迎指正。对于该系统更深入的话题，就不做表述了，一是希望每个设计者能自行思考，毕竟吃别人嚼过的馍，不香；二是篇幅有限，写的太多，个人耗费太多；三是该系列仅是个人对以往工作经验的感想，而非总结，因此其丰富性，全面性要差一些。