首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

腾讯云基于英特尔® DLB 技术实现多核无锁化限速方案

作为全球领先的云服务提供商之一,腾讯云*致力于向全球用户提供性能卓越的企业级网络服务。公有云对于服务质量有着严苛的要求,计算、内存、网络以及存储等各项资源的分配能否满足服务水平协议中所承诺的标准,都将直接影响最终用户的应用体验。对于云服务提供商来说,如何在充分利用以上资源,满足服务水平协议的前提下,尽可能减少额外资源开销,也是降低运营成本的关键因素之一。为在降低成本的同时保证优质的服务质量,腾讯云携手深度合作伙伴英特尔,基于腾讯云应用程序界面 (Application Programming Interfaces, API) TGW 与腾讯专门的硬件工程实验室 星星海实验室的创新软硬件结合方案,发挥 TGW 在网络领域的技 术优势,针对网络资源调度及分配展开性能优化。

01

无锁环形缓冲区的详细解释

由以下博客的分析可以知道,内核的kfifo使用了很多技巧以实现其高效性。比如,通过限定写入的数据不能溢出和内存屏障实现在单线程写单线程读的情况下不使用锁。因为锁是使用在共享资源可能存在冲突的情况下。还用设置buffer缓冲区的大小为2的幂次方,以简化求模运算,这样求模运算就演变为 (fifo->in & (fifo->size – 1))。通过使用unsigned int为kfifo的下标,可以不用考虑每次下标超过size时对下表进行取模运算赋值,这里使用到了无符号整数的溢出回零的特性。由于指示读写指针的下标一直在增加,没有进行取模运算,知道其溢出,在这种情况下写满和读完就是不一样的标志,写满是两者指针之差为fifo->size,读完的标志是两者指针相等。后面有一篇博客还介绍了VxWorks下的环形缓冲区的实现机制点击打开链接,从而可以看出linux下的fifo的灵巧性和高效性。

03

理解上下文切换带来的性能影响

在多任务操作系统中,为了提高CPU的利用率,可以让当前系统运行远多于CPU核数的线程。但是由于同时运行的线程数是由CPU核数来决定的,所以为了支持更多的线程运行,CPU会把自己的时间片轮流分给其他线程,这个过程就是上下文切换。   导致上下文切换的原因有很多,比如通过wait()、sleep()等方法阻塞当前线程,这时CPU不会一直等待,而是重新分配去执行其他线程。当后续CPU重新切换到当前线程时,CPU需要沿着上次执行的指令位置继续运行。因此,每次在CPU切换之前,需要把CPU寄存器和程序计数器保存起来,这些信息会存储到系统内核中,CPU再次调度回来时会从系统内核中加载并继续执行。简而言之,上下文切换,就是CPU把自己的时间片分配给不同的任务执行的过程。

04

java多线程中的死锁、活锁、饥饿、无锁都是什么鬼?

死锁、活锁、饥饿是关于多线程是否活跃出现的运行阻塞障碍问题,如果线程出现了这三种情况,即线程不再活跃,不能再正常地执行下去了。 死锁 死锁是多线程中最差的一种情况,多个线程相互占用对方的资源的锁,而又相互等对方释放锁,此时若无外力干预,这些线程则一直处理阻塞的假死状态,形成死锁。 举个例子,A同学抢了B同学的钢笔,B同学抢了A同学的书,两个人都相互占用对方的东西,都在让对方先还给自己自己再还,这样一直争执下去等待对方还而又得不到解决,老师知道此事后就让他们相互还给对方,这样在外力的干预下他们才解决,当然

09
领券