继IoT，工业自动化，5G通信等热门领域的在线研讨会成功举办后，世强硬创电商此次将目光聚焦到了智能传感器。11月20日，世强硬创新产品在线研讨会——智能传感器专场的开展，邀请了Amphenol Sensors，TE，Silicon Labs，Xsens等国际顶尖品牌发布压力/温度/湿度/位置/角度/光电/霍尔等涵盖全品类的传感器最新产品，吸引到来自阿里巴巴，华为，中移物联网，小米等知名企业，共计超1000名研发工程师参会。不少企业组织员工集中参会，在内部形成一定规模的交流学习氛围。 据悉，传感器行业巨头TE的高精度，功耗低至2.7μW的温湿度传感器，Silicon Labs效果媲美Polar的动态心率血氧监测方案，Melexis可承受160℃工作温度的第三代位置传感器……都一一发布于在此次世强硬创新产品在线研讨会，资深技术专家与参会者深入了探讨传感器智能化，低能耗，高精度等产品发展方向。 世强硬创新产品在线研讨会——智能传感器专场所有视频和讲义资料都已上线世强硬创电商平台，前往官网即可了解详情。

企业数字化转型是当今的热门话题之一，数字化转型可以帮助企业走向信息化，运用最新科技增强自身实力，同时也将不再单独依赖硬件，通过软硬件结合构建一套完整的数字化解决方案。 包括西门子，罗克韦尔，ABB，施耐德等在内的国际一线厂商，他们在早年通过收购或者兼并一些软件厂商，不仅充实了自身的软实力，还使自己提前实现了较高程度的数字化转型，并且根据自己的经验，建立了一套软硬件结合的数字化解决方案。 与他们相比，目前大多数国内工业企业则表现为普遍缺乏数字化转型经验；面对日益紧迫转型升级需求，本土工业企业希望能得到上述有经验国际大厂的协助，共同开发和构建一套完整的工业数字化解决方案。 西门子入华已超过140年，目前与多家头部厂商进行过合作，为需求方提供了各类定制数字化转型解决方案，尤其是在成都、青岛、武汉、东莞、长沙等地建立的智能制造创新中心，更是成为当地厂商数字化转型的有力支撑。 不过数字化转型需要因地制宜，仅仅套用模版化的解决方案并不奏效，所以国内厂商急需一套“中国化”的数字化转型解决方案。西门子在近日召开数字化工业软件用户大会，正式推出西门子数字化工业软件2030中国战略，这套战略是以西门子多年来的数字化转型经验为基础，深耕国内厂商转型痛点，定制了一套专属的转型战略。 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

引子 小艾吃饭路上碰上小牛，忙问：你昨天面大厂面的咋样了？听说他们最喜欢问多线程相关知识。 小牛说：对啊，第一个问题我就讲了20分钟，直接把面试官讲服了。 小艾忙问：什么问题能讲这么久？是不是问你情感经历了？ 小牛说：…问的volatile关键字。 小艾说：volatile关键词的作用一般有如下两个： 可见性：当一个线程修改了由volatile关键字修饰的变量的值时，其它线程能够立即得知这个修改。 有序性：禁止编译器关于操作volatile关键词修饰的变量的指令重排序。 你说这两个说了20分钟？口吃？ 小牛说：你知道volatile的实现原理吗？ 小艾说：缓存一致性协议嘛，这有啥？ 小牛说：既然硬件保证了缓存一致性协议，无论该变量是否被volatile关键词修饰，它都该满足缓存一致性协议呀。你这说的有点自相矛盾哦。 小艾说：那volatile的实现原理是什么？ 小牛说：且听我慢慢道来。 缓存一致性协议 我们知道，现代CPU都是多核处理器。由于cpu核心（Kernel）读取内存数据较慢，于是就有了缓存的概念。我们希望针对频繁读写的某个内存变量，提升本核心的访问速率。因此我们会给每个核心设计缓存区(Cache)，缓存该变量。由于缓存硬件的读写速度比内存快，所以通过这种方式可以提升变量访问速度。缓存的结构可以如下设计： 缓存结构图 其中，一个缓存区可以分为N个缓存行(Cache line)，缓存行是和内存进行数据交换的最小单位。每个缓存行包含三个部分，其中valid用于标识该数据的有效性。如果有效位为false，CPU核心就从内存中读取，并将对应旧的缓存行数据覆盖，否则使用旧缓存数据；tag用于指示数据对应的内存地址；block则用以存储数据， 多核缓存和内存 但是，如果涉及到并发任务，多个核心读取同一个变量值，由于每个核心读取的是自己那一部分的缓存，每个核心的缓存数据不一致将会导致一系列问题。缓存一致性的问题根源就在于，对于某个变量，好几个核心对应的缓存区都有，到底哪个是新的数据呢？如果只有一个CPU核心对应的缓存区有该变量，那就没事啦，该缓存肯定是新的。 所以为了保证缓存的一致性，业界有两种思路： 写失效(Write Invalidate)：当一个核心修改了一份数据，其它核心如果有这份数据，就把valid标识为无效； 写更新(Write update)：当一个核心修改了一份数据，其它核心如果有这份数据，就都更新为新值，并且还是标记valid有效。 业界有多种实现缓存一致性的协议，诸如MSI、MESI、MOSI、Synapse、Firefly Dragon Protocol等，其中最为流行的是MESI协议。 MESI协议就是根据写失效的思路，设计的一种缓存一致性协议。为了实现这个协议，原先的缓存行修改如下： 缓存结构图 原先的valid是一个比特位，代表有效/无效两种状态。在MESI协议中，该位改成两位，不再只是有效和无效两种状态，而是有四个状态，分别为： M（Modified）：表示核心的数据被修改了，缓存数据属于有效状态，但是数据只处于本核心对应的缓存，还没有将这个新数据写到内存中。由于此时数据在各个核心缓存区只有唯一一份，不涉及缓存一致性问题； E（Exclusive）：表示数据只存在本核心对应的缓存中，别的核心缓存没这个数据，缓存数据属于有效状态，并且该缓存中的最新数据已经写到内存中了。同样由于此时数据在各个核心缓存区只有一份，也不涉及缓存一致性问题； S（Shared）：表示数据存于多个核心对应的缓存中，缓存数据属于有效状态，和内存一致。这种状态的值涉及缓存一致性问题； I（Invalid）：表示该核心对应的缓存数据无效。 看到这里，大家想必知道为什么这个协议称为MESI协议了吧，它的命名就是取了这四个状态的首字母而已。为了保证缓存一致性，每个核心要写新数据前，需要确保其他核心已经置同一变量数据的缓存行状态位为Invalid后，再把新数据写到自己的缓存行，并之后写到内存中。 MESI协议包含以下几个行为： 读（Read）：当某个核心需要某个变量的值，并且该核心对应的缓存没这个变量时，就会发出读命令，希望别的核心缓存或者内存能给该核心最新的数据； 读命令反馈（Read Response）：读命令反馈是对读命令的回应，包含了之前读命令请求的数据。举例来说，Kernel0发送读命令，请求变量a的值，Kernel1对应的缓存区包含变量a，并且该缓存的状态是M状态，所以Kernel1会给Kernel0的读命令发送读命令反馈，给出该值； 无效化（Invalidate）：无效化指令是一条广播指令，它告诉其他所有核心，缓存中某个变量已经无效了。如果变量是独占的，只存在某一个核心对应的缓存区中，那就不存在缓存一致性问题了，直接在自己缓存中改了就行，也不用发送无效化指令； 无效化确认（Invalidate Acknowledge）：该指令是对无效化指令的回复，收到无效化指令的核心，需要将自己缓存区对应的变量状态改为Invalid，并回复无效化确认，以此保证发送无效化确认的缓存已经无效了； 读无效（Read Invalidate）:这个命令是读命令和无效化命令的综合体。它需要接受读命令反馈和无效化确认； 写回（Writeback）这个命令的意思是将核心中某个缓存行对应的变量值写回到内存中去。 下图给了个一个应用MESI读写数据的例子。在该图中，假设CPU有两个核心，Kernel0表示第一个核心，Kernel1表示第二个核心。这里给出了Kernel0想写新数据到自己缓存的例子。 首先Kernel0先完成新数据的创建； Kernel0向全体其他核心发送无效化指令，告诉其他核心其所对应的缓存区中的这条数据已经过期无效。本图例中只有一个其他核心，为Kernel1； 其他核心收到广播消息后，将自己对应缓存的数据的标志位记为无效，然后给Kernel0回确认消息； 收到所有其他Kernel的确认消息后，Kernel0才能将新数据写回到它所对应的缓存结构中去。 根据上图，我们可以发现，影响MESI协议的时间瓶颈主要有两块： 无效化指令：Kernel0需要通知所有的核心，该变量对应的缓存在其他核心中是无效的。在通知完之前，该核心不能做任何关于这个变量的操作。 确认响应：Kernel0需要收到其他核心的确认响应。在收到确认消息之前，该核心不能做任何关于这个变量的操作，需要持续等待其他核心的响应，直到所有核心响应完成，将其对应的缓存行标志位设为Invalid，才能继续其它操作。 针对这两部分，我们可以进一步优化： 针对无效化指令的加速：在缓存的基础上，引入Store Buffer这个结构。Store Buffer是一个特殊的硬件存储结构。通俗的来讲，核心可以先将变量写入Store Buffer，然后再处理其他事情。如果后面的操作需要用到这个变量，就可以从Store Buffer中读取变量的值，核心读数据的顺序变成Store Buffer → 缓存 → 内存。这样在任何时候核心都不用卡住，做不了关于这个变量的操作了。引入Store Buffer后的结构如下所示： Store Buffer结构 针对确认响应的加速：在缓存的基础上，引入Invalidate Queue这个结构。其他核心收到Kernel0的Invalidate的命令后，立即给Kernel0回Acknowledge，并把Invalidate这个操作，先记录到Invalidate Queue里，当其他操作结束时，再从Invalidate Queue中取命令，进行Invalidate操作。所以当Kernel0收到确认响应时，其他核心对应的缓存行可能还没完全置为Invalid状态。引入Invalidate Queue后的结构如下所示： Invalidate Queue结构 缓存一致性协议优化存在的问题 上一节讲了两种缓存一致性协议的加速方式。但是这两个方式却会对缓存一致性导致一定的偏差，下面我们来看一下两个出错的例子： 例子1：关于Store Buffer带来的错误，假设CPU有两个核心，Kernel0表示第一个核心，Kernel1表示第二个核心。 ...public void foo(){    a=1;    b=1;}public void bar(){    while(b==0) continue;    assert(a==1):"a has a wrong value!";}... 如果Kernel0执行foo()函数，Kernel1执行bar()函数，按照之前我们的理解，如果b变量为1了，那a肯定为1了，assert(a==1)肯定不会报错。但是事实却不是这样的。 假设初始情况是这样的：在执行两个函数前Kernel1的缓存包含变量a=0，不包含缓存变量b，Kernel0的缓存包含变量b=0，不包含缓存变量a。Kernel0执行foo()函数，Kernel1执行bar()函数时，。这样的话计算机的指令程序可能会如下展开： Kernel0执行a=1。由于Kernel0的缓存行不包含变量a，因此Kernel0会将变量a的值存在Store Buffer中，并且向其他Kernel进行read Invalidate操作，通知a变量缓存无效； Kernel1执行while(b==0)，由于Kernel1的缓存没有变量b，因此它需要发送一个读命令，去找b的值； Kernel0执行b=1，由于Kernel0的缓存中已经有了变量b，而且别的核心没有这个变量的缓存，所以它可以直接更改缓存b的值； Kernel0收到读命令后，将最新的b的值发送给Kernel1，并且将变量b的状态由E（独占）改变为S（共享）； Kernel1收到b的值后，将其存到自己Kernel对应的缓存区中； Kernel1接着执行while(b==0)，因为此时b的新值为1，因此跳出循环； Kernel1执行assert(a==1)，由于Kernel1缓存中a的值为0，并且是有效的，所以断言出错； Kernel1终于收到了第一步Kernel0发送的Invalidate了，赶紧将缓存区的a==1置为invalid，但是为时已晚。 所以我们看到，这个例子出错的原因完全是由Store Buffer这个结构引发的。如果规定将Store Buffer中数据完全刷入到缓存，才能执行对应变量写操作的话，该错误也能避免了。 例子2：关于Invalidate Queue带来的错误，同样假设CPU有两个核心，Kernel0表示第一个核心，Kernel1表示第二个核心。 ...public void foo(){    a=1;    b=1;}public void bar(){    while(b==0) continue;    assert(a==1):"a has a wrong value!";}... Kernel0执行foo()函数，Kernel1执行bar()函数，猜猜看这次断言会出错吗？ 假设在初始情况是这样的：变量a的值在Kernel0和Kernel1对应的缓存区都有，状态为S（共享），初值为0，变量b的值是0，状态为E（独占），只存在于Kernel1对应的缓存区，不存在Kernel0对应的缓存区。假设Kernel0执行foo()函数，Kernel1执行bar()函数时，程序执行过程如下： Kernel0执行a=1，此时由于a变量被更改了，需要给Kernel1发送无效化命令，并且将a的值存储在Kernel0的Store Buffer中； Kernel1执行while(b==0)，由于Kernel1对应的缓存不包含变量b，它需要发出一个读命令； Kernel0执行b=1，由于是独占的，因此它直接更改自己缓存的值； Kernel0收到读命令，将最新的b的值发送给Kernel1，并且将变量b的状态改变为S（共享）； Kernel1收到Kernel0在第一步发的无效化命令，将这个命令存到Invalidate Queue中，打算之后再处理，并且给Kernel0回确认响应； Kernel1收到包含b值的读命令反馈，把该值存到自己缓存下； Kernel1收到b的值之后，打破while循环； Kernel1执行assert(a==1)，由于此时Invalidate Queue中的无效化a=0这个缓存值还没执行，因此Kernel1会接着用自己缓存中的a=1这个缓存值，这就出现了问题； Kernel1开始执行Invalidate Queue中的命令，将a=0这个缓存值无效化。但这时已经太晚了。 所以我们看到，这个例子出错的原因完全是由Invalidate Queue这个结构引发的。如果规定将Invalidate Queue中命令完全处理完，才能执行对应变量读操作的话，该错误也能避免了。 内存屏障 既然刚刚我们遇到了问题，那如何改正呢？这里就终于到了今天的重头戏，内存屏障了。内存屏障简单来讲就是一行命令，规定了某个针对缓存的操作。这里我们来看一下最常见的写屏障和读屏障。 针对Store…

点击上方“大鱼机器人”，选择“置顶/星标公众号” 福利干货，第一时间送达！ 指针对于C来说太重要。然而，想要全面理解指针，除了要对C语言有熟练的掌握外，还要有计算机硬件以及操作系统等方方面面的基本知识。所以本文尽可能的通过一篇文章完全讲解指针。 为什么需要指针？ 指针解决了一些编程中基本的问题。 指针的使用使得不同区域的代码可以轻易的共享内存数据。当然小伙伴们也可以通过数据的复制达到相同的效果，但是这样往往效率不太好。 因为诸如结构体等大型数据，占用的字节数多，复制很消耗性能。 但使用指针就可以很好的避免这个问题，因为任何类型的指针占用的字节数都是一样的（根据平台不同，有4字节或者8字节或者其他可能）。 指针使得一些复杂的链接性的数据结构的构建成为可能，比如链表，链式二叉树等等。 有些操作必须使用指针。如操作申请的堆内存。 还有：C语言中的一切函数调用中，值传递都是“按值传递”的。 如果我们要在函数中修改被传递过来的对象，就必须通过这个对象的指针来完成。 计算机是如何从内存中进行取指的？ 计算机的总线可以分为3种：数据总线，地址总线和控制总线。这里不对控制总线进行描述。数据总线用于进行数据信息传送。数据总线的位数一般与CPU的字长一致。 一般而言，数据总线的位数跟当前机器int值的长度相等。例如在16位机器上，int的长度是16bit，32位机器则是32bit。这个计算机一条指令最多能够读取或者存取的数据长度。大于这个值，计算机将进行多次访问。这也就是我们说的64位机器进行64位数据运算的效率比32位要高的原因，因为32位机要进行两次取指和运行，而64位机却只需要一次！ 地址总线专门用于寻址，CPU通过该地址进行数据的访问，然后把处于该地址处的数据通过数据总线进行传送，传送的长度就是数据总线的位数。地址总线的位数决定了CPU可直接寻址的内存空间大小，比如CPU总线长32位，其最大的直接寻址空间长232KB，也就是4G。 这也就是我们常说的32位CPU最大支持的内存上限为4G（当然，实际上支持不到这个值，因为一部分寻址空间会被映射到外部的一些IO设备和虚拟内存上。现在通过一些新的技术，可以使32位机支持4G以上内存，但这个不在这里的讨论范围内）。 一般而言，计算机的地址总线和数据总线的宽度是一样的，我们说32位的CPU，数据总线和地址总线的宽度都是32位。 计算机访问某个数据的时候，首先要通过地址总线传送数据存储或者读取的位置，然后在通过数据总线传送需要存储或者读取的数据。一般地，int整型的位数等于数据总线的宽度，指针的位数等于地址总线的宽度。   计算机的基本访问单元   学过C语言的人都知道，C语言的基本数据类型中，就属char的位数最小，是8位。我们可以认为计算机以8位，即1个字节为基本访问单元。小于一个字节的数据，必须通过位操作来进行访问。   内存访问方式 如图1所示，计算机在进行数据访问的时候，是以字节为基本单元进行访问的，所以可以认为，计算每次都是从第p个字节开始访问的。访问的长度将由编译器根据实际类型进行计算，这在后面将会进行讲述。   内存访问方式   想要了解更多，就去翻阅计算机组成原理和编译原理吧。   sizeof关键字 sizeof关键字是编译器用来计算某些类型的数据的长度的，以字节为基本单位。例如： sizeof(char)=1; sizeof(int)=4; sizeof(Type)的值是在编译的时候就计算出来了的，可以认为这是一个常量！ 指针是什么？ 我们知道：C语言中的数组是指一类类型，数组具体区分为  int 类型数组，double类型数组,char数组 等等。 同样指针这个概念也泛指一类数据类型，int指针类型，double指针类型，char指针类型等等。 通常，我们用int类型保存一些整型的数据，如 int num = 97 ， 我们也会用char来存储字符：char ch = ‘a’。 我们也必须知道：任何程序数据载入内存后，在内存都有他们的地址，这就是指针。 而为了保存一个数据在内存中的地址，我们就需要指针变量。 因此：指针是程序数据在内存中的地址，而指针变量是用来保存这些地址的变量。   在我个人的理解中，可以将指针理解成int整型，只不过它存放的数据是内存地址，而不是普通数据，我们通过这个地址值进行数据的访问，假设它的是p，意思就是该数据存放位置为内存的第p个字节。 当然，我们不能像对int类型的数据那样进行各种加减乘除操作，这是编译器不允许的，因为这样错是非常危险的！ 图2就是对指针的描述，指针的值是数据存放地址，因此，我们说，指针指向数据的存放位置。   指针的长度 我们使用这样的方式来定义一个指针： Type *p; 我们说p是指向type类型的指针，type可以是任意类型，除了可以是char,short, int, long等基本类型外，还可以是指针类型，例如int *, int **, 或者更多级的指针，也可是是结构体，类或者函数等。于是，我们说： int * 是指向int类型的指针； int **，也即(int *) *，是指向int *类型的指针，也就是指向指针的指针； int ***，也即(int **) *，是指向int**类型的指针，也就是指向指针的指针的指针； …我想你应该懂了 struct xxx *，是指向struct xxx类型的指针； 其实，说这么多，只是希望大家在看到指针的时候，不要被int ***这样的东西吓到，就像前面说的，指针就是指向某种类型的指针，我们只看最后一个*号，前面的只不过是type类型罢了。 细心一点的人应该发现了，在“什么是指针”这一小节当中，已经表明了：指针的长度跟CPU的位数相等，大部分的CPU是32位的，因此我们说，指针的长度是32bit，也就是4个字节！注意：任意指针的长度都是4个字节，不管是什么指针！（当然64位机自己去测一下，应该是8个字节吧。。。）  于是： Type *p; izeof(p)的值是4，Type可以是任意类型，char,int, long, struct, class, int **… 以后大家看到什么sizeof(char*), sizeof(int *)，sizeof(xxx *)，不要理会，统统写4，只要是指针，长度就是4个字节，绝对不要被type类型迷惑！   为什么程序中的数据会有自己的地址？ 弄清这个问题我们需要从操作系统的角度去认知内存。 电脑维修师傅眼中的内存是这样的：内存在物理上是由一组DRAM芯片组成的。 而作为一个程序员，我们不需要了解内存的物理结构，操作系统将RAM等硬件和软件结合起来，给程序员提供的一种对内存使用的抽象。 这种抽象机制使得程序使用的是虚拟存储器,而不是直接操作和使用真实存在的物理存储器。 所有的虚拟地址形成的集合就是虚拟地址空间。 在程序员眼中的内存应该是下面这样的。 也就是说，内存是一个很大的，线性的字节数组（平坦寻址）。每一个字节都是固定的大小，由8个二进制位组成。 最关键的是，每一个字节都有一个唯一的编号,编号从0开始，一直到最后一个字节。 如上图中，这是一个256M的内存，他一共有256x1024x1024  = 268435456个字节，那么它的地址范围就是 0 ~268435455  。…

11月28日，由第一财经、财经网、时代传媒集团和价值线研究院联合主办的2020中国资本年会在江苏无锡举行，会议以“聚焦中国经济新赛道”为主题，邀请了全国上市领先地区政府官员、经济学家、投行业界领袖、优秀上市公司董事长等齐聚一堂，围绕中国经济新赛道，深度研讨了中国经济和城市竞争力的未来之路，借以推动科技、资本和实体经济高质量循环、高效发展。 （图片来源：网络）

中国汽车行业一级综合性供应商——联合汽车电子有限公司(United Automotive Electronic Systems Co., Ltd. ，以下简称“UAES”)与全球知名半导体制造商罗姆(ROHM Co., Ltd.，以下简称“罗姆”)在中国上海的UAES总部成立了“SiC技术联合实验室”，并于2020年10月举行了启动仪式。 UAES副总经理 郭晓潞(右)与罗姆半导体(上海)有限公司 董事长 藤村 雷太(左)在启动仪式上互赠纪念品 与IGBT*1等Si(硅)功率元器件相比，SiC功率元器件具有“开关损耗和传导损耗*2小”、“耐温度变化能力强”等优势，因而作为一种能够显著降低损耗的半导体，在电动汽车以及基础设施、环境/能源、工业设备领域的应用日益广泛。 UAES和罗姆自2015年开始技术交流以来，双方在采用SiC功率元器件的车载应用产品开发方面建立了合作伙伴关系。经过多年的技术交流，采用了罗姆SiC功率元器件的UAES车载产品于今年成功投入量产。 此次成立的联合实验室配备了重要设备，包括能够对车载充电器和DC/DC转换器等车载应用产品进行整机评估的测试设备、以及能够进行元器件评估的测试装置等。 未来，双方将会进一步加强合作关系，并加快以SiC为核心的创新型电源解决方案的开发。 UAES副总经理 郭晓潞表示：“自2015年罗姆为UAES推介SiC功率元器件产品以来，双方包括高层在内的交流不断加深。作为多年技术交流的成果，UAES开发出采用了SiC的车载应用并在今年成功实现量产，对此我们表示非常高兴。该联合实验室的成立，表明两家公司之间的合作关系进一步加深，我们期待通过完善的设备，得到更出色的技术支持。” 罗姆董事高级执行官CSO兼功率元器件业务统括 伊野和英博士表示：“我们很高兴能够与车载应用领域的先进企业——UAES成立联合实验室。作为SiC功率元器件的先进厂商，罗姆正在推进行业先进的元器件开发，同时，通过与驱动IC等外围元器件相结合的电源解决方案，获得了傲人的实际应用业绩。未来，在市场有望继续扩大的车载领域，把握客户需求和市场动向的研究将是非常重要的要素，因此，双方将通过联合实验室加强合作关系，并凭借以SiC为核心的电源解决方案为汽车技术革新做出贡献。”

德国.哥廷根, 2020年12月10日– 2020年11月24日Bourns 与德国Kaschke KG(GmbH and Co)向德国联邦政府卡特尔办公室正式提出公司合并申请事宜。德国Kaschke KG(GmbH and Co)为知名定制电感组件和铁氧体的市场领先设计商和制造商，其母公司Kaschke Components GmbH同样是欧洲知名半导体及电子组件制造商。 Bourns 表示提交该文件的目的是希望当地政府允许双方建立全球战略合作伙伴关系，以开发新的磁性产品，包括:电源变压器和扼流圈，替客户打造高效，稳健的电源器。 Bourns与Kaschke持续针对战略联盟的形式和条款进行讨论，一旦获得合并批准并满足一定的结案条件，该战略联盟即有望达成。 双方首选的战略合作伙伴关系形式是股权收购，这将使原与Kaschke交易的客户和供货商合同以及Kaschke全球员工的聘雇安排在此交易结束亦不受影响。 本次策略合作关系将Kaschke广泛的定制设计、特有铁氧体知识，结合Bourns专业应用的知识，来设计出独特的新产品，相信这结合会带来新的火花，也为工业和替代能源市场带来新的价值。 Kaschke总裁Silke Baumgartner 表示:「我很高兴能与Bourns建立联盟，Bourns的历史和核心价值观与Kaschke完全一致。我们相信Kaschke和Bourns的结合将使我们能够开发出完整的产品组合，帮助我们的客户满足汽车，工业和新能源市场中下一代电源所面临的充满挑战的EMI滤波要求。此外这些新产品将使客户可以通过简单的设计和成本优化来满足他们的设计目标。」 Bourns.总裁兼首席运营官Al Yost同时表示:「透过新材料和快速的切换速度来降低开关损耗使得半导体产业向前迈向一大步。我们很高兴与Kaschke合作开发新产品，现在正是需要新的磁性材料和产品来跟上趋势。以增强新一代电源能量转换。」

1. 落寞的小黑 入冬了，最近天气相当冷，周五晚上小林下班奔地铁站，收到了好基友小黑的微信: 于是 小林掉头扫了个单车奔五道口了，小黑靠谱地选了个不错的位置。 小黑: 你今天下班挺早呀！ 小林: 就咱这觉悟，心里有工作，哪里都是办公桌，不要拘泥于形式嘛。 明显能感觉得到小黑哥最近好像比较累，之前眼里bulingbuling闪的光是看不到了。 小林: 下午去面的哪家？啥岗位？咋样？ 小黑: 是一家做自动驾驶的创业公司，网站是看团队介绍还不错，就去看看了，这次没咋准备，很多问题其实都熟悉，但是回答的不到位。 小林: 哦，明白了，那就是当时理解的不到位，稀里糊涂过去了，现在忽然问起来，想不起重点。 小黑: 差不多吧，问我都做过哪些高性能的网络框架模型，也就是IO和事件驱动那一套。 话说完，小黑喝了一大口啤酒，小林看出了小黑心里有一些落寞。 毕竟在帝都这个地方竞争和工作压力，以及生活琐事都一直围绕着我们，但是金钱和好运都巧妙地避开了自己… 想到这里，小林也深深喝了一大口，我命由我不由天，开整！ 小林：黑哥，你说这个问题确实不好回答，全是术语和略带歧义的东西，我觉得我们抓住本质去阐述就好。 小黑：来，请开始你的表演，我学习学习。 小林决定和小黑好好聊聊，Linux开发中常用的高性能网络框架中的一些事儿，火锅的映衬下让夜色和天气都不那么寒冷了。 通过本文你将会了解到以下内容： IO事件和IO复用 线程模型和事件驱动模型的架构 基于事件驱动的Reactor模式详解 同步IO和异步IO简介 2. IO事件和IO复用 2.1 什么是IO事件 IO指的是输入Input/输出Output，但是从汉语角度来说，出和入是相对的，所以我们需要个参照物。 这里我们的参照物选择为程序运行时的主存储空间，外部通常包括网卡、磁盘等。 有了上述的设定理解起来就方便多了，我们来一起看下： IO的本质是数据的流动，数据可以从网卡到程序内存，也可以从程序内存写到网卡，磁盘操作也是如此。 所以可以把常见的IO分为: 网络IO：内存和网卡的数据交互 文件IO：内存和磁盘的数据交互 那什么又是IO事件呢？ 事件可以理解为一种状态或者动作，也就是状态的迁移会触发一种相应的动作。 网络IO的事件通常包括： 可读事件 可写事件 异常事件 理解可读可写事件是非常有必要的，一般来说一个socket大部分时候是可写的，但是并不是都可读。 可读一般代表是一个新连接或者原有连接有新数据交互，对于服务端程序来说也是重点关注的事件。 2.2 什么是IO复用 设想假如有几万个IO事件，那么应用程序该如何管理呢？这就要提到IO复用了。 IO复用从本质上来说就是应用程序借助于IO复用函数向内核注册很多类型的IO事件，当这些注册的IO事件发生变化时内核就通过IO复用函数来通知应用程序。 从图中可以看到，IO复用中复用的就是一个负责监听管理这些IO事件的线程。 之所以可以实现一个线程管理成百上千个IO事件，是因为大部分时间里某个时刻只有少量IO事件被触发。 大概就像这样： 草原上的一只大狗可以看管几十只绵羊，因为大部分时候只有个别绵羊不守规矩乱跑，其他的都是乖乖吃草。 3. 网络框架设计要素 要理解网络框架有哪些，必须要清楚网络框架完成了哪些事情。 大致描述下这个请求处理的流程： 远端的机器A发送了一个HTTP请求到服务器B，此时服务器B网卡接收到数据并产生一个IO可读事件; 我们以同步IO为例，此时内核将该可读事件通知到应用程序的Listen线程; Listen线程将任务甩给Handler线程，由Handler将数据从内核读缓冲区拷贝到用户空间读缓冲区; 请求数据包在应用程序内部进行计算和处理并封装响应包; Handler线程等待可写事件的到来; 当这个连接可写时将数据从用户态写缓冲区拷贝到内核缓冲区，并通过网卡发送出去; 备注：上述例子是以同步IO为例，并且将线程中的角色分为Listen线程、Handler线程、Worker线程，分别完成不同的工作，后续会详细展开。 所以我们可以知道，要完成一个数据交互，涉及了几大块内容： IO事件监听 数据拷贝 数据处理和计算 小林认为，这三大块内容，不论什么形式的框架都绕不开，也是理解网络架构的关键所在。 4. 高性能网络框架实践 4.1 基于线程模型 在早期并发数不多的场景中，有一种One Request One Thread的架构模式。 该模式下每次接收一个新请求就创建一个处理线程，线程虽然消耗资源并不多，但是成千上万请求打过来，性能也是扛不住的。 这是一种比较原始的架构，思路也非常清晰，创建多个线程来提供处理能力，但在高并发生产环境中几乎没有应用，本文不再展开。 4.2 基于事件驱动模型 当前流行的是基于事件驱动的IO复用模型，相比多线程模型优势很明显。 在此我们先理解一下什么是事件驱动Event-Drive-Model。 事件驱动编程是一种编程范式，程序的执行流由外部事件来决定，它的特点是包含一个事件循环，当外部事件发生时使用回调机制来触发相应的处理。 通俗来说就是： 有一个循环装置在一直等待各种事件的到来，并将到达的事件放到队列中，再由一个分拣装置来调用对应的处理装置来响应。 4.3 Reactor反应堆模式 第一次听到这个模式的时候很困惑，究竟反应堆是个啥？ 研究了一下发现，反应堆是个核物理的概念，大致是这个样子的： 核反应堆是核电站的心脏 ，它的工作原理是这样的：原子由原子核与核外电子组成，原子核由质子与中子组成。 当铀235的原子核受到外来中子轰击时，一个原子核会吸收一个中子分裂成两个质量较小的原子核，同时放出2-3个中子。 这裂变产生的中子又去轰击另外的铀235原子核，引起新的裂变， 如此持续进行就是裂变的链式反应。 结合这种核裂变的图，好像 是一个请求打过来，服务器内部瞬间延伸出很多分支来完成响应，一变二，二变四，甚至更多，确实有种反应堆的感觉。 接下来我们看看究竟反应堆模式是如何构建高性能网络框架的。 5.反应堆模式详解 反应堆模式是一种思想，形式却有很多种。 5.1 反应堆模式的本质是什么 从本质上理解，无论什么网络框架都要完成两部分操作： IO操作：数据包的读取和写入 CPU操作：数据请求的处理和封装 所以上述这些问题 由谁来做以及多少线程来做，就衍生出了很多形式，所以不要被表面现象迷惑，出现必有原因，追溯之后我们才能真正掌握它。 反应堆模式根据处理IO环节和处理数据环节的数量差异分为如下几种： 单Reactor线程 单Reactor线程和线程池 多Reactor线程和线程池 我们来看看这三种常见模式的特点、原理、优缺点、应用场景等。 5.2 单Reactor线程模式 这种模式最为简洁，一个线程完成了连接的监听、接收新连接、处理连接、读取数据、写入数据全套工作。 由于只使用了一个线程，对于多核利用率偏低，但是编程简单。 是不是觉得这个种单线程的模式没有市场？那可未必，不信你看Redis。…

今天上午，华为如约发布鸿蒙OS 2.0的手机开发者Beta版。同时面向开发者开启公测，华为P40 、P40 Pro、Mate 30、Mate 30 Pro、MatePad Pro等设备，抢先体验。 从媒体的现场体验来看，鸿蒙OS 2.0的手机开发者Beta版可兼容运行安卓应用，目前在UI设计上和基于安卓的EMUI11没什么区别，流畅度和EMUI 11相仿。 鸿蒙OS 2.0手机开发者Beta版 EMUI 11 也就是说，鸿蒙OS 2.0的手机开发者Beta版只是系统底层有所更改，原本底层是安卓，现在换成了鸿蒙，UI、UX与EMUI 11基本没有变化。 从曝光的鸿蒙OS 2.0的手机开发者Beta版“关于手机”界面来看，基本是EMUI 11的翻版。最大的不同是，前者显示HarmonyOS版本为11.0.1，没有了Android版本一栏。 按照华为此前规划，明年，华为智能手机将全面升级鸿蒙OS 2.0。据悉，升级EMUI 11的用户，将优先获得升级鸿蒙OS 2.0的机会。 以下为鸿蒙OS 2.0手机开发者Beta版界面： 来源：快科技

在智慧路灯建设需求巨大的今天，LED灯杆屏的应用热度似乎从不褪减，几乎每一个智慧路灯项目都可见LED灯杆屏，开启全新路灯应用时代。 可以说，LED灯杆屏的出现，突破了路灯应用领域的常规化，在分分合合中实现了在应用领域的进一步深入。LED灯杆屏是安装在灯杆上的显示屏，是LED显示屏市场的一个细分领域。它是集数字化、网络化、信息化于一身的新一代媒体设备，能够为整个智慧路灯项目承载内容传播、碎片化应用和智能管理等要务。 然而，LED灯杆屏越来成为智慧路灯项目中不可缺少的配套应用，但是由于集成、成本等问题，LED灯杆屏价格是项目承包商较为关注的一个问题。 作为智慧灯杆产业中不可缺少并且作为重要配套应用——信息发布的LED灯杆屏，在目前许许多多的试点项目中得到了应用，并且开启了一场智慧显示的新浪潮。LED灯杆屏的配套应用更是为智慧灯杆的智慧管理带来更多的便利和提升更大的应用价值。 实际上，抛开产品本身不谈，红利爆发期对于LED灯杆屏厂家来说同样是一个考验和挑战，如何才能够在发展的洪流中站稳脚跟，聚势前行呢？对LED灯杆屏来说，这是一次重要的产业机遇，通过节点的升级改造以及传输技术的优化升级，LED灯杆屏在路灯领域的应用将会更加智能和节能，把应用体验再提升一个档次。 而让LED灯杆屏趋势席卷另一股重要力量就是5G商用的临近。5G商用时代的到来，助推了智慧灯杆产业的结构升级，无论是从硬件还是功能、业务上都会有很大的改变。LED灯杆屏在大市场、大跨界、大推动力的作用下更是承载更多的智慧价值，以信息化改造为亮点，以智能化升级为契机，以运营收益为“筹码”，进一步支撑智慧城市应用，呈现出新的竞争优势。 另一方面，LED灯杆屏作为智慧显示行业的“续航者”，起到了不可替代的作用，而智慧路灯产业多样化的架构也决定了其对于智慧的需求更具挑战性，LED灯杆屏各方面的演进正好符合这种需求。 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！