多核系统中三种典型锁竞争的加速比分析

最新推荐文章于 2023-06-04 22:36:40 发布

itkbase

最新推荐文章于 2023-06-04 22:36:40 发布

阅读量962

点赞数

文章标签：任务 stream object parallel microsoft 服务器软件

本文链接：https://blog.youkuaiyun.com/itkbase/article/details/2001837

版权

本文探讨了多核系统中三种锁竞争形式对程序性能加速比的影响，包括固定式、随机式和分布式锁竞争。分析了任务粒度因子与锁粒度因子对加速比的作用，并给出每种竞争形式下的加速比计算公式。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

多核系统中三种典型锁竞争的加速比分析

1.1 引言

1.6 结论

1.1 引言

在多核系统中，衡量程序性能的一个重要指标就是加速比，加速比定义如下：

S(n) ＝单处理器上最优串行化算法计算时间 / 使用n个处理器并行计算时间

众所周知，关于加速比有一个阿姆达尔定律，说的是加速比方面的事情，即加速比S(n) 和串行部分所占比例f 有关，而与CPU 核数n 无关，也就是说

当处理器个数n 趋近于无穷大时，有以下等式。

阿姆达尔定律的提出让整个软件界灰心了许多年，因为只要串行比例为5 ％，那么不论增加多少处理器，加速比最多也只能达到20 。

若干年后一个叫Gustafson 的人提出了和阿姆达尔定律不同的意见，得到了一个新的加速比公式如下：

其中的K 是一个常数，表示串行执行时间所占的比例。

按照Gustafson 定律，加速比显然和CPU 核数n 是成正比的，CPU 核数越大，加速比也越大。

Gustafson 定律的前提条件假设串行化代码的规模是固定的，计算规模是随CPU 核数增加而增加的。实际情况中，共享资源访问的计算量和程序的计算规模是成正比的，如果共享资源通过锁保护操作而变成串行化执行的话，那么串行化代码的规模将随程序规模的增加而线性增加，这样将导致不符合Gustafson 定律的前提条件，而是符合阿姆达尔定律的前提条件。最终得出的加速比将是按照阿姆达尔定律计算出结果。

因此如何消除锁竞争造成的串行化执行就成了程序员需要解决的问题，下面就来先看一下几种不同类型的锁竞争形式对加速比指标的具体影响，在锁竞争的情况中，任务粒度因子和锁粒度因子是影响加速比的重要因素之一，因此需要先看一下任务粒度因子和锁粒度因子的概念。

1.2 任务粒度因子与锁粒度因子

在一个有锁保护操作的程序中，每个任务中的计算可以分为如下图所示的几部分：

图1 ：任务内的计算分类

其中

t _s －表示锁内计算时间，大小由共享资源的操作时间决定，与共享资源类型有关，并且与程序员的程序设计有关。

t _l －表示 Lock操作和Unlock操作耗费的时间，如果CPU核的速度固定，那么它为一常量。

t _p －表示锁外可并行计算部分耗费的时间，大小与具体的应用类型及程序员的分解有关

为了形象地表示出各段计算间的比例关系，引入两个概念：任务粒度因子和锁粒度因子。

1. 任务粒度因子

任务粒度因子主要是用来反映一个任务的计算量大小，由t _l是常量，因此把任务内的有效计算和t _l的比值叫做任务粒度因子，记为：

2. 锁粒度因子

锁粒度因子反映了一个任务内锁操作的粒度关系，用锁内计算和t _l的比值来表示锁粒度因子，记为：

1.3 固定式锁竞争中的加速比分析

在一个固定式锁竞争情况中，是由若干个同时创建的对等任务竞争同一把锁，在这种固定式竞争环境中，假设每个任务都执行一次锁内操作，锁竞争一定会发生并因锁竞争而导致任务排队串行执行锁操作及锁内计算。固定式锁竞争属于实际情况中的常见现象，比如使用前面提到过的OpenMP来创建任务，如果在任务中使用了锁操作的话，那么它就是一种固定式锁竞争。

固定式锁竞争的情况在这篇文章：多核编程中的锁竞争难题里做过分析，如果用前面的任务粒度因子和锁粒度因子代入的话，可以得到固定式锁竞争的加速比如下：

1.4 随机锁竞争中的加速比分析

在实际情况中，除了上节讲过的固定式锁竞争情况外，锁竞争还有一种随机竞争的形式，在多核编程中的任务随机竞争模式的概率分析一文中对随机锁竞争做过分析。

在随机锁竞争中，各个对等任务运行锁计算的时间是随机的。比如在服务器软件中，各个任务创建后，每个任务都在循环地做同样的计算，而各个任务的运行时间受网络客户端的影响，其处理时间不是固定的，而是随机的，这样将导致各个任务在竞争同一把锁时出现随机竞争现象。

随机锁竞争情况下的加速比期望值如下：

n 随机锁竞争最坏情况下的加速比

上面计算出的加速比是期望值，在最坏情况下，实际上有

的概率所有的任务都处于锁内计算状态，在这种最坏情况下，只有一个任务在运行，因此加速比为1，如果考虑锁计算开销，那么加速比为

在最坏的情况下，加速比将小于1。

1.5 分布式锁竞争的加速比分析

在一个分布式锁竞争环境中，有多个任务竞争多把不同的锁，不妨设有m个任务竞争r把不同的锁。

如果任务数量m足够大的话，那么运行锁外计算的任务数量将会大于CPU核数，导致每个CPU核上都有任务在运行，此时的多CPU效率为

，

可以看出这种情况下的加速比和CPU核数成正比，并和任务粒度因子有关，任务粒度因子越大，那么加速比也越大。此时加速比和锁粒度没有任何关系。这是分布式锁竞争和普通锁竞争的最大区别。

如果任务数量m不够大，运行锁外计算的任务数量小于CPU核数的话，那么需要计算在有多少个进行锁竞争的任务在运行。

为方便起见，令k为运行锁内计算的任务数量，那么这k个任务在竞争r把锁，假设有

鈥?鈥濆簲鐢ㄧ▼搴忎腑鐨勬湇鍔″櫒閿欒銆?hr width=100% size=1 color=silver>

鍙傛暟鏃犳晥銆?/i>

璇存槑: 鎵ц褰撳墠 Web 璇锋眰鏈熼棿锛屽嚭鐜版湭澶勭悊鐨勫紓甯搞€傝妫€鏌ュ爢鏍堣窡韪俊鎭紝浠ヤ簡瑙ｆ湁鍏宠閿欒浠ュ強浠ｇ爜涓鑷撮敊璇殑鍑哄鐨勮缁嗕俊鎭€?

寮傚父璇︾粏淇℃伅: System.ArgumentException: 鍙傛暟鏃犳晥銆?br>
婧愰敊璇?

鍙湁鍦ㄨ皟璇曟ā寮忎笅杩涜缂栬瘧鏃讹紝鐢熸垚姝ゆ湭澶勭悊寮傚父鐨勬簮浠ｇ爜鎵嶄細鏄剧ず鍑烘潵銆傝嫢瑕佸惎鐢ㄦ鍔熻兘锛岃鎵ц浠ヤ笅姝ラ涔嬩竴锛岀劧鍚庤姹?URL: 1. 鍦ㄤ骇鐢熼敊璇殑鏂囦欢鐨勯《閮ㄦ坊鍔犱竴鏉♀€淒ebug=true鈥濇寚浠ゃ€備緥濡? <%@ Page Language="C" Debug="true" %> 鎴? 2. 灏嗕互涓嬬殑鑺傛坊鍔犲埌搴旂敤绋嬪簭鐨勯厤缃枃浠朵腑: 璇锋敞鎰忥紝绗簩涓楠ゅ皢浣跨粰瀹氬簲鐢ㄧ▼搴忎腑鐨勬墍鏈夋枃浠跺湪璋冭瘯妯″紡涓嬭繘琛岀紪璇戯紱绗竴涓楠や粎浣胯鐗瑰畾鏂囦欢鍦ㄨ皟璇曟ā寮忎笅杩涜缂栬瘧銆?br> 閲嶈浜嬮」: 浠ヨ皟璇曟ā寮忚繍琛屽簲鐢ㄧ▼搴忎竴瀹氫細浜х敓鍐呭瓨/鎬ц兘绯荤粺寮€閿€銆傚湪閮ㄧ讲鍒扮敓浜ф柟妗堜箣鍓嶏紝搴旂‘淇濆簲鐢ㄧ▼搴忚皟璇曞凡绂佺敤銆?/code>

鍫嗘爤璺熻釜:

[ArgumentException: 鍙傛暟鏃犳晥銆俔 System.Drawing.Image.FromStream(Stream stream, Boolean useEmbeddedColorManagement, Boolean validateImageData) +388134 System.Drawing.Image.FromStream(Stream stream) +8 Dottext.Admin.UploadWord.SaveFile(HttpPostedFile File) +32 Dottext.Admin.UploadWord.Page_Load(Object sender, EventArgs e) +76 System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +15 System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +34 System.Web.UI.Control.OnLoad(EventArgs e) +99 System.Web.UI.Control.LoadRecursive() +47 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061

鐗堟湰淇℃伅: Microsoft .NET Framework 鐗堟湰:2.0.50727.832; ASP.NET 鐗堟湰:2.0.50727.832