fpcc的专栏

国外的框架库，一个比较让人头疼的就是里面用了非常多的其它相关的库。这样的好处当然很明显，就是完成具体的工作的效率会大幅提高。但对于学习者来说就比较麻烦了，需要不断的学习这个库那个库，然后才能把整个框架运行起来并初步掌握。但真正掌握后会发现，写这方面的代码会简单很多，至少比自己想象的要简单很多！如果做应用开发的话，这确实是一个好的方法！

老生常谈的技术，可能对于不少开发者已经耳朵都听出茧子来了。可还是要说，为什么？这就和上学一样，你觉得你会了，而且你也明白了整个过程，甚至把作业都作得很好，可考试呢？大多数人仍然是一个中上游的水平。要是明白这个现象产生的道理，就明白现在这里说的什么道理。熟能生巧，但很难产生思想！大家自己意会！

技术的进步就是朝着简化开发者的应用的方向展开的。包括现在的AI，虽然说当下AI取代程序员可能有点忽悠的成分，但未来这种是大概率的事件。至少大多数的普通程序员被AI替代是一种非常可能的情况。这个时间可能不会很长。但这并不代表程序员的消失，反而有可能会出现另外一种形式的程序员。大家拭目以待吧！

其实多线程如此，多进程大抵亦也如此！只不过目前来看写多进程的已经非常少了。总结到最后，多线程的安全退出只有一条原则，就是让每个线程自己正常退出，而不是暴力打断它的执行。只要贯彻了这一原则，就不会出现多线程退出的各种异常问题。可是，实际的场景复杂又多变，有的时候确实无法等待所有的线程正常的退出，这就需要开发者自己根据情况进行取舍。有舍才有得，亘古不变的道理！

早就跟大家一起分享过，一定要抓住事物本质。针对软件就是找到其应用的目的，其核心思想是什么，而不是简单的说哪种技术好，哪种技术不好。最合适的就最好的，而这个最合适一定是随着应用的发展不断的变化的。孤立的、片面的和僵化的看问题，就很容易陷入到无何止的争论中去。教条主义、本本主义和经验主义，其实大家都犯，但一定要记得打破这层牢笼。否则，就会固步自封，难建寸功。所以科学和哲学，往往是无法分开的。这也是学习一些思想的目的和原因。

通过这些年来看国外的框架和库，有一个粗浅的经验即国外一般是互相引用互相借鉴，不大怎么重复造轮子。这个在Java上非常明显，就是一引用就是一大群库或框架。或者一个框架中有一批其它的库，而其它的库又引用其它的库，C++中也是如此。国内的的相对封闭许多，大多都是自我工作，一般都是在内部引用一些库或者一些国外非常有名的库。这样说的意思是说国内的软件开发环境其实相对国外要差不少，仍然需要进一步的提高。当然，国内的开发环境也不是一天两天的原因更不是某个人某些人造成的，需要大家一起努力。

一个好汉三个帮。完成一个并行任务，也需要一些辅助的模块共同作用。这种利用配置文件来进行节点管理的方法，虽然谈不上多新奇，但成熟可靠，正好应用在医学领域。

其实在研读Supra代码的过程中，最大的受益并不是TBB技术的学习，而是在设计思想上的又一次提高。对如何实事求是，因地制宜的进行技术设计有了一个更清晰的认知和验证。所以说多看代码，多分析源码，受益匪浅！

它是一个开源的超声实时应用软件，主要是在医学领域的超声数据的图像重建和输出，同时允许在图像数据的处理过程中对其进行完善和修改。它支持CPU和GPU两种模式，支持2D和3D图像的格式。SUPRA的整体的框架基础是在TBB的框架基础上进行设计的，它在TBB的任务、节点等抽象的层次上又进行了一次抽象的封装，让其更接近于人们的认知形态。之所以从SUPRA框架入手，最主要的就是其在设计上有机的整合了TBB框架，将业务逻辑更好的与TBB框架的设计再次抽象，在整体流程实现的过程中，实现了业务逻辑与底层技术的动态组合。

任务调度在哪儿都是一种非常让人纠结的事情。就像一个大厨，有一两个人时，饭菜就容易为所有人所表扬，可当面对上百人时，可能就有不少人给差评了。所以一个好的框架，不但要提供默认的管理调度手段，也要提供针对个性化的定制场景的接口。既要面对主流，也要取悦小众。难点，在于一个平衡！做为开发者，要从学习代码的最初的功能到学习其架构，在到其整体的设计思想，这才是最终极的目标。

任务调试器等于是TBB底层提供的一种基础控制流程的手段。它既是一个非常强大的应用方式，也是一种很复杂很难驾驭的任务调度方式，所以TBB的应用中，尽量还是多使用其上层封装好的相关并行算法和任务调度模板。这就和汽车一样，主流的情况下请采用自动档驾驶，但遇到一些特殊情况，可以使用手动方式进行驾驶。万物相通，道理相同！

从TBB框架中的任务可以瞥见一种趋势，即在设计上对底层进一步封装，特别是对一些复杂的如线程、进程以及IO的操作。尽量屏蔽与硬件结合较紧密的部分功能，从而在更高的抽象上实现对目标的解耦。而解耦的最终目的，就是让整个框架的适应性更广泛，应用更灵活。这也是做为开发者学习框架的一个重要的原因和目的。最后，学会了一定要学以致用。

在前面分析过了节点相关的应用和功能，也在其中分析过一些节点的数据定义情况。本文就对节点的数据定义进行一个更详细具体的分析说明，特别是对一些应用上的细节展开说明一下。知其然，然后知其所以然。节点的定义，基本都是以模板进行的。所以希望大家有一些基本的模板的知识，否则看起来还是有些麻烦的。

不同的节点有着不同的处理机制，而实际的应用场景千变万化。到达罗马的大路不止一条，何况还有小路。所以，正确的选择可能有很多，但如果寻找一条更适合当前环境的设计思路，这才是重点。最好不一定合适，合适其实从某种意义上说才是最好。

一个好的框架，必然是容易使用。不光是接口让开发者感觉良好，环境安装也要相对简单。否则除了一些技术极客对大多数开者来说，可能安装就被劝退了。这种情况还是比较常见的。比如早期的Eclipse就被后来的idea给抢占了大半的江山。而在Windows平台上，Vistual Studio一直是一座绕不过去的大山。就是因为这两者都是容易安装和使用，一般不会有什么需要具体的配置才能进行正确的进行开发。简单是永远是方向，至于简单到何种地步，就见仁见智了。

锁的底层机制就是对资源的限制性利用，在效率和安全下寻求一个平衡。无论是现实世界还是计算机世界，资源的有限性才造就了竞争，而要让资源被安全的最大化利用，就需要一种管理机制，在现实世界，就是法律和道德；在计算机世界就是锁。锁，其实就是计算机中的权力的象征！谁拥有了它，就可以自由的使用资源来工作。

其实在实际应用中，二者的应用大多是泾渭分明的。但真正的细节上的区别，还是需要认真的掌握。不然在开发具体的工程时，可能会一时疏忽导致不可预测的问题和错误。还是那句话，细节决定成败，但不能拘泥于细节。这个度，就需要开发者自己不断养成自己的判断。

纸上学来终觉浅啊，还是要亲自跑一下代码。实践和理论一起向前推进，才能更好的理解相关的程序代码和其内在的运行机制。

TBB框架有很多细节需要处理，但勿需焦虑。很多的细节其实在应用的时候儿就会自然的出现，不明白再去查阅相关的文档即可。重点是掌握好其整体的逻辑流程，抓大放小，强干弱枝。还是那句话，细节很重要，但不要限入细节不可自拔。

在TBB中，可以理解任务分解、处理和并行这种机制开放给了应用开发者，而并行的实现和并行间的同步以及与实际线程和缓冲等数据处理，由TBB框架自行完成。这样，开发者更专注于实际的业务而对底层的并行实现透明处理。它的优势在于抽象隔离了底层并发的复杂性，实现了业务层面的聚焦。不过，这种方式的实现需要有一个前提，需要开发者对并行及其相关的实现有相当的了解，否则在遇到复杂的业务逻辑时，出现各种问题反而更不容易解决。总之，事物总有其两面性，辩证的看问题吧。