目錄

8.1。概觀

8.1.1。多線程編程范例8.1.2。POSIX線程編程模型8.1.3。多線程編程問題8.1.4。數據競賽檢測

8.2。使用DRD

8.2.1。DRD命令行選項8.2.2。檢測到的錯誤：數據競賽8.2.3。檢測到的錯誤：鎖定爭用8.2.4。檢測到的錯誤：濫用POSIX線程API8.2.5?？蛻舳苏埱?/span>8.2.6。調試C ++ 11程序8.2.7。調試GNOME程序8.2.8。調試Boost.Thread程序8.2.9。調試OpenMP程序8.2.10。DRD和自定義內存分配器8.2.11。DRD與Memcheck8.2.12。資源要求8.2.13。有效使用DRD的提示和提示

8.3。有效地使用POSIX線程API

8.3.1?；コ忸愋?/span>8.3.2。條件變量8.3.3。pthread_cond_timedwait和超時

8.4。限制8.5。反饋

要使用此工具，必須--tool=drd?在Valgrind命令行上指定?。

8.1。概觀

DRD是用于檢測多線程C和C ++程序中的錯誤的Valgrind工具。該工具適用于使用POSIX線程原語的任何程序，或者使用構建在POSIX線程圖元之上的線程概念。

8.1.1。多線程編程范例

在程序中使用多線程有兩個可能的原因：

• 模擬并發活動。與單個線程中多個活動的狀態復用相比，將一個線程分配給每個活動可以是一個很好的簡化。這就是為什么大多數服務器軟件和嵌入式軟件都是多線程的。

• 同時使用多個CPU內核來加速計算。這就是為什么許多高性能計算（HPC）應用程序是多線程的。

多線程程序可以使用以下一個或多個編程范例。哪個范例適合取決于應用程序類型。多線程編程范例的一些例子是：

• 鎖定。通過線程共享的數據可以通過鎖定進行并發訪問。例如POSIX線程庫，Qt庫和Boost.Thread庫直接支持該范例。

• 消息傳遞。線程之間沒有共享數據，但線程通過相互傳遞消息來交換數據。消息傳遞范例的實現示例是MPI和CORBA。

• 自動并行化?編譯器將順序程序轉換為多線程程序。原始程序可能包含也可能不包含并行化提示。這種并行化提示的一個例子是OpenMP標準。在本標準中，定義了一組指令，告訴編譯器如何并行化C，C ++或Fortran程序。OpenMP非常適合于計算密集型應用。例如，開源圖像處理軟件包正在使用OpenMP來最大化具有多個CPU內核的系統的性能。GCC支持4.2.0版的OpenMP標準。

• 軟件事務內存（STM）。通過事務更新線程之間共享的任何數據。每個交易之后，驗證是否存在任何沖突的交易。如果存在沖突，則該事務被中止，否則就被提交。這是一種所謂的樂觀態度。有一個支持STM的Intel C ++編譯器的原型。關于向海灣合作委員會增加STM支持的研究正在進行之中。

只要這些范例的實現基于POSIX線程圖元，DRD就支持多線程編程范例的任何組合。然而，DRD不支持直接使用例如Linux'futexes的程序。嘗試用DRD分析這些程序將導致DRD報告許多假陽性。

8.1.2。POSIX線程編程模型

POSIX線程，也稱為Pthreads，是Unix系統上最廣泛使用的線程庫。

POSIX線程編程模型基于以下抽象：

• 共享地址空間。在同一進程內運行的所有線程共享相同的地址空間。所有數據（無論是否共享）都由其地址標識。

• 定期加載和存儲操作，允許從同一進程中運行的所有線程共享的內存讀取值或向其寫入值。

• 原子存儲和加載修改存儲操作。雖然這些在POSIX線程標準中沒有提及，但大多數微處理器都支持原子內存操作。

• 線程。每個線程表示并發活動。

• 同步對象和這些同步對象的操作。在POSIX線程標準中定義了以下類型的同步對象：互斥體，條件變量，信號量，讀寫器同步對象，障礙和自旋鎖。

哪些源代碼語句生成哪些內存訪問取決于正在使用的編程語言的內存模型。C和C ++語言還沒有一個確定的內存模型。對于內存模型草案，另見文檔?WG21 / N2338：并發內存模型編譯器的后果。

有關POSIX線程的更多信息，另請參閱單一UNIX規范版本3，也稱為?IEEE Std 1003.1。

8.1.3。多線程編程問題

根據程序中使用的多線程范例，可能會出現以下一個或多個問題：

• 數據競賽?一個或多個線程訪問相同的內存位置，而沒有足夠的鎖定。大多數但不是所有的數據競賽都是編程錯誤，并且是微妙和難以發現的錯誤的原因。

• 鎖定爭用?一個線程通過持有鎖太長來阻止一個或多個其他線程的進度。

• 不正確的使用POSIX線程API。POSIX線程API的大多數實現已針對運行速度進行了優化。這樣的實現不會對某些錯誤抱怨，例如當互斥體被另一個線程解鎖時，而不是獲得互斥鎖上的鎖的線程。

• 僵局。當兩個或多個線程無限期地等待彼此時，會發生死鎖。

• 虛假分享?如果在不同處理器核心上運行的線程經常訪問位于同一高速緩存行中的不同變量，那么由于高速緩存線的頻繁交換，這將減慢涉及的線程。

盡管數據競賽發生的可能性可以通過有紀律的編程風格來降低，但是在開發多線程軟件時，必須使用自動檢測數據競賽的工具。DRD可以檢測這些，以及鎖定爭用和不正確使用POSIX線程API。

8.1.4。數據競賽檢測

由多線程程序執行的加載和存儲操作的結果取決于執行內存操作的順序。此訂單由以下決定：

由同一線程執行的所有存儲器操作都按?程序順序執行，即由程序源代碼確定的順序和先前加載操作的結果。

同步操作確定由不同線程執行的存儲器操作的某些排序約束。這些排序約束稱為同步順序。

程序順序和同步順序的組合稱為?發生之前的關系。這一概念首先由S.Adve等人在“?檢測弱記憶體系數據競賽”（ACM SIGARCH Computer Architecture News，v.19 n.3，p.234-243，1991年5月）中定義。

如果兩個操作都是由不同的線程執行的，則?兩個內存操作沖突，指的是相同的內存位置，其中至少有一個是存儲操作。

如果所有沖突的存儲器訪問是通過同步操作排序的，則多?線程程序是數據競爭的。

確保多線程程序無數據資源的眾所周知的方法是確保遵守鎖定規則。例如，可以將互斥體與每個共享數據項相關聯，并且在訪問共享數據時對相關聯的互斥體進行鎖定。

遵循鎖定規則的所有程序都是數據競賽的，但并不是所有無數據競爭的程序都遵循鎖定規則。存在多線程程序，其中通過條件變量，信號量或障礙來對共享數據進行訪問。作為一個例子，一類HPC應用程序由一系列計算步驟組成，這些步驟在時間上由障礙隔開，而這些障礙是唯一的同步手段。盡管在這些應用程序中存在許多沖突的存儲器訪問，盡管這樣的應用程序不能使用互斥體，但是這些應用程序大多數不包含數據種族。

在運行時驗證多線程程序的正確性存在兩種不同的方法。所謂的擦除算法的方法是驗證所有共享存儲器訪問是否遵循一致的鎖定策略。并且發生之前的數據競爭檢測器直接驗證所有的連接間存儲器訪問是否通過同步操作排序。雖然最后一種方法實現起來更加復雜，雖然它對OS調度更加敏感，但它是一種通用的方法，適用于所有類的多線程程序。發生在數據競爭檢測器之前的一個重要優點是這些不報告任何誤報。

DRD是基于之前的算法。

8.2。使用DRD

8.2.1。DRD命令行選項

以下命令行選項可用于控制DRD工具本身的行為：

--check-stack-var=<yes|no> [default: no]

控制DRD是否檢測堆棧變量上的數據競爭。默認情況下禁用驗證堆棧變量，因為大多數程序不會通過線程共享堆棧變量。

--exclusive-threshold=<n> [default: off]

如果任何互斥鎖或寫卡器鎖定的時間長于指定的時間（毫秒），則打印錯誤消息。此選項可以檢測鎖爭用。

--join-list-vol=<n> [default: 10]

如果內存訪問信息在線程加入后立即被丟棄，則可能會錯過在一個線程的結尾處的語句和另一個線程之間發生的數據競爭。此選項允許指定應保留多少連接的線程內存訪問信息。

--first-race-only=<yes|no> [default: no]

是否僅報告在內存位置檢測到的第一個數據競賽或在內存位置檢測到的所有數據競賽。

--free-is-write=<yes|no> [default: no]

是否報告訪問內存和釋放內存之間的比賽。啟用此選項可能會導致DRD運行速度稍慢。筆記：

• 使用自定義內存分配器時，請勿啟用此選項VG_USERREQ__MALLOCLIKE_BLOCK?，VG_USERREQ__FREELIKE_BLOCK?因為會導致誤報。

• 使用引用計數的對象時，不要啟用該選項，因為這將導致誤報，即使該代碼已與正確注釋?ANNOTATE_HAPPENS_BEFORE?和ANNOTATE_HAPPENS_AFTER。有關示例，請參見以下命令的輸出：?valgrind --tool=drd --free-is-write=yes drd/tests/annotate_smart_pointer。

--report-signal-unlocked=<yes|no> [default: yes]

是否在信號發送時通過或?未被鎖定來報告與該信號相關聯的互斥體的呼叫?pthread_cond_signal和?pthread_cond_broadcast在哪里?。發送一個信號而不用鎖定相關的互斥體是常見的編程錯誤，可能導致微妙的競爭條件和不可預知的行為。存在一些不尋常的同步模式，但是可以安全地發送信號而不對相關聯的互斥鎖進行鎖定。?pthread_cond_waitpthread_cond_timed_wait

--segment-merging=<yes|no> [default: yes]

控制段合并。段合并是一種限制數據競爭檢測算法的內存使用的算法。禁用段合并可能提高競賽報告中顯示的所謂“其他段”的準確性，但也可能會觸發內存不足錯誤。

--segment-merging-interval=<n> [default: 10]

僅在創建指定數量的新細分后才執行細分合并。這是一個高級配置選項，可以選擇是否通過選擇較低的值來最小化DRD的內存使用率，或者通過選擇略高的值來讓DRD運行得更快。該參數的最佳值取決于正在分析的程序。默認值適用于大多數程序。

--shared-threshold=<n> [default: off]

如果讀卡器鎖定時間超過指定時間（以毫秒為單位），則打印錯誤消息。此選項可以檢測鎖爭用。

--show-confl-seg=<yes|no> [default: yes]

在比賽報告中顯示相互沖突的細分。由于此信息可以幫助您找到數據競爭的原因，默認情況下會啟用此選項。禁用此選項可使DRD的輸出更加緊湊。

--show-stack-usage=<yes|no> [default: no]

在線程退出時打印堆棧使用情況。當程序創建大量線程時，限制為線程堆棧分配的虛擬內存量變得非常重要。該選項使得可以觀察到客戶端程序的每個線程已經使用了多少堆棧內存。注意：DRD工具本身在客戶端線程堆棧上分配一些臨時數據。這個臨時數據所需的空間必須由客戶端程序分配堆棧內存，但不包括在DRD報告的堆棧使用中。

--ignore-thread-creation=<yes|no> [default: no]

控制線程創建過程中是否應忽略所有活動。默認情況下僅在Solaris上啟用。Solaris提供了比其他操作系統更高的吞吐量，并行性和可擴展性，代價是更細粒度的鎖定活動。這意味著例如，當在glibc下創建一個線程時，所有線程設置只使用一個大鎖。Solaris libc使用幾個細粒度的鎖，并且創建者線程盡快恢復其活動，例如堆棧和TLS設置順序到創建的線程。這種情況混淆了DRD，因為它假定在創建者和創建的線程之間存在一些錯誤的順序;?因此，不會報告申請中的許多類型的種族條件。?yes為了防止這種錯誤排序， 在Solaris上默認情況下將此命令行選項設置為。所有活動（加載，存儲，客戶端請求）因此在以下期間被忽略：

• pthread_create（）在創建者線程中調用

• 線程創建階段（堆棧和TLS設置）在創建的線程中

以下選項可用于監視客戶端程序的行為：

--trace-addr=<address> [default: none]

跟蹤指定地址的所有加載和存儲活動。此選項可以被指定多次。

--ptrace-addr=<address> [default: none]

跟蹤指定地址的所有加載和存儲活動，并保持這樣做，即使在該地址的內存已被釋放并重新分配。

--trace-alloc=<yes|no> [default: no]

跟蹤所有內存分配和釋放。可能產生大量的產量。

--trace-barrier=<yes|no> [default: no]

跟蹤所有障礙活動。

--trace-cond=<yes|no> [default: no]

跟蹤所有條件變量活動。

--trace-fork-join=<yes|no> [default: no]

跟蹤所有線程創建和所有線程終止事件。

--trace-hb=<yes|no> [default: no]

跟蹤的執行ANNOTATE_HAPPENS_BEFORE()，?ANNOTATE_HAPPENS_AFTER()以及?ANNOTATE_HAPPENS_DONE()客戶端請求。

--trace-mutex=<yes|no> [default: no]

跟蹤所有互斥體活動。

--trace-rwlock=<yes|no> [default: no]

跟蹤所有讀寫器鎖定活動。

--trace-semaphore=<yes|no> [default: no]

跟蹤所有信號量活動。

8.2.2。檢測到的錯誤：數據競賽

每次檢測到數據競賽時，DRD會打印一條消息。在解釋DRD的輸出時，請記住以下幾點：

• 每個線程由DRD工具分配一個線程ID。線程ID是一個數字。線程ID從一開始就永遠不會被回收。

• 術語段是指連續的負載，存儲和同步操作序列，全部由同一個線程發出。段始終在同步操作中開始和結束。由于性能原因，在段之間進行數據競爭分析，而不是在單獨的負載和存儲操作之間進行。

• 在數據競賽中總是至少有兩個內存訪問。涉及數據競爭的內存訪問稱為?沖突存儲器訪問。DRD打印一份與過去內存訪問沖突的每個內存訪問的報告。

下面您可以找到DRD在檢測到數據競賽時打印的消息的示例：

$ valgrind --tool = drd --read-var-info = yes drd / tests / rwlock_race ... == 9466 ==主題3： == 9466 ==線程3在0x006020b8大小的沖突負載4 == 9466 ==在0x400B6C：thread_func（rwlock_race.c：29） == 9466 == by 0x4C291DF：vg_thread_wrapper（drd_pthread_intercepts.c：186） == 9466 == by 0x4E3403F：start_thread（in /lib64/libpthread-2.8.so） == 9466 == by 0x53250CC：clone（in /lib64/libc-2.8.so） == 9466 ==位置0x6020b8是本地var“s_racy”內的0個字節 == 9466 ==在rwlock_race.c中聲明：18，在線程3的框架＃0中 == 9466 ==其他段啟動（線程2） == 9466 == at 0x4C2847D：pthread_rwlock_rdlock *（drd_pthread_intercepts.c：813） == 9466 == by 0x400B6B：thread_func（rwlock_race.c：28） == 9466 == by 0x4C291DF：vg_thread_wrapper（drd_pthread_intercepts.c：186） == 9466 == by 0x4E3403F：start_thread（in /lib64/libpthread-2.8.so） == 9466 == by 0x53250CC：clone（in /lib64/libc-2.8.so） == 9466 ==其他段末（線程2） == 9466 == at 0x4C28B54：pthread_rwlock_unlock *（drd_pthread_intercepts.c：912） == 9466 == by 0x400B84：thread_func（rwlock_race.c：30） == 9466 == by 0x4C291DF：vg_thread_wrapper（drd_pthread_intercepts.c：186） == 9466 == by 0x4E3403F：start_thread（in /lib64/libpthread-2.8.so） == 9466 == by 0x53250CC：clone（in /lib64/libc-2.8.so） ...

上述報告具有以下含義：

• 左側列中的數字是由DRD分析的進程的進程ID。

• 第一行（“線程3”）告訴您線程的線程ID，在哪個上下文中檢測到數據競爭。

• 下一行告訴執行哪種操作（加載或存儲）以及哪個線程。同一行也顯示沖突訪問中涉及的起始地址和字節數。

• 接下來，顯示沖突訪問的調用堆棧。如果您的程序已使用調試信息（-g）進行編譯，則此調用堆棧將包含文件名和行號。此調用堆棧（clone?和start_thread）中的兩個最底層框架顯示了NPTL如何啟動一個線程。第三幀（vg_thread_wrapper）由DRD添加。第四幀（thread_func）是第一個有趣的行，因為它顯示了線程入口點，即作為第三個參數傳遞的函數?pthread_create。

• 接下來，顯示沖突地址的分配上下文。對于動態分配的數據，顯示分配調用堆棧。對于靜態變量和堆棧變量，只有在指定了該選項時才會顯示分配上下文?--read-var-info=yes。否則DRD將打印Allocation context: unknown。

• 沖突訪問涉及至少兩個內存訪問。對于這些訪問之一，顯示精確的調用堆棧，并且對于其他訪問，顯示近似調用堆棧，即其他訪問段的開始和結束。該信息可以解釋如下：

• 從兩個調用堆棧的底部開始，并對具有相同功能名稱，文件名和行號的數量堆棧幀進行計數。在上述例子中三個最下面的幀是相同的（clone，?start_thread和?vg_thread_wrapper）。

• 兩個調用堆棧中的下一個更高的堆棧幀現在告訴您在哪個源代碼區域中發生了其他內存訪問。上述輸出告訴數據競爭中涉及的其他內存訪問發生在文件中的源代碼行28和30之間?rwlock_race.c。

8.2.3。檢測到的錯誤：鎖定爭用

線程必須能夠進行而不被其他線程阻塞太久。有時，線程必須等到互斥體或讀寫器同步對象被另一個線程解鎖。這被稱為?鎖爭用。

鎖爭用導致延遲。這種拖延應盡可能短。兩個命令行選項?--exclusive-threshold=<n>，并?--shared-threshold=<n>通過使DRD報告任何持續時間超過指定閾值的鎖，可以檢測到過多的鎖爭用。一個例子：

$ valgrind --tool = drd --exclusive-threshold = 10 drd / tests / hold_lock -i 500 ... == 10668 ==收購于： == 10668 == at 0x4C267C8：pthread_mutex_lock（drd_pthread_intercepts.c：395） == 10668 == by 0x400D92：main（hold_lock.c：51） == 10668 ==鎖定互斥量0x7fefffd50在503 ms（閾值：10 ms）內保持。 == 10668 == at 0x4C26ADA：pthread_mutex_unlock（drd_pthread_intercepts.c：441） == 10668 == 0x400DB5：main（hold_lock.c：55） ...

hold_lock只要由-i（interval）參數指定?，測試程序就會保存一個鎖。DRD輸出報告在源文件中在線路51獲取hold_lock.c并在線55釋放的鎖定在?503ms內保持，而對DRD指定了10ms的閾值。

8.2.4。檢測到的錯誤：濫用POSIX線程API

DRD能夠檢測并報告POSIX線程API的以下濫用情況：

• 將一種類型的同步對象（例如互斥體）的地址傳遞到期望具有指向另一類型同步對象（例如條件變量）的指針的POSIX API調用。

• 嘗試解鎖未鎖定的互斥體。

• 嘗試解鎖被另一個線程鎖定的互斥體。

• 嘗試PTHREAD_MUTEX_NORMAL遞歸地鎖定類型或螺旋鎖的互斥體?。

• 鎖定的互斥體的銷毀或釋放。

• 將信號發送到條件變量，而與條件變量相關聯的互斥體上沒有鎖定。

• 調用pthread_cond_wait未鎖定的互斥體，被另一個線程鎖定或遞歸鎖定的互斥體。

• 將兩個不同的互斥體與條件變量相關聯pthread_cond_wait。

• 正在等待的條件變量的銷毀或釋放。

• 鎖定的讀寫器同步對象的銷毀或釋放。

• 嘗試解鎖未被調用線程鎖定的讀寫器同步對象。

• 嘗試遞歸地鎖定讀寫器同步對象。

• 嘗試將用戶定義的讀寫器同步對象的地址傳遞給POSIX線程函數。

• 嘗試將POSIX讀寫器同步對象的地址傳遞給用戶定義的讀寫器同步對象的注釋之一。

• 互斥體，條件變量，讀寫器鎖定，信號量或屏障的重新初始化。

• 正在等待的信號燈或屏障的銷毀或釋放。

• 屏障等待和屏障破壞之間缺少同步。

• 退出一個線程，而不會首先解鎖該線程鎖定的自旋鎖，互斥鎖或讀寫器同步對象。

• 將無效的線程ID傳遞給pthread_join?或pthread_cancel。

8.2.5?？蛻舳苏埱?/h3>

就像其他Valgrind工具一樣，有可能讓客戶端程序通過客戶端請求與DRD工具進行交互。除了客戶端請求之外，還定義了一些允許以便利的方式使用客戶端請求的宏。

頭文件中定義了客戶端程序與DRD工具之間的接口<valgrind/drd.h>。可用的宏和客戶端請求是：

• 宏DRD_GET_VALGRIND_THREADID和相應的客戶端請求VG_USERREQ__DRD_GET_VALGRIND_THREAD_ID。查詢由Valgrind核心分配給執行此客戶端請求的線程的線程ID。Valgrind的線程ID從一個開始，如果線程停止則被回收。

• 宏DRD_GET_DRD_THREADID和相應的客戶端請求VG_USERREQ__DRD_GET_DRD_THREAD_ID。查詢由DRD分配給執行此客戶端請求的線程的線程ID。這些是DRD在數據競賽報告和跟蹤消息中報告的線程ID。DRD的線程ID從一開始就永遠不會被回收。

• 宏DRD_IGNORE_VAR(x)，?ANNOTATE_TRACE_MEMORY(&x)和相應的客戶端請求VG_USERREQ__DRD_START_SUPPRESSION。一些應用程序包含有意的種族。存在例如從兩個不同線程將共享變量分配給相同值的應用程序。抑制這種種族可能比解決這些種族更為方便。該客戶端請求允許抑制這種種族。

• 宏DRD_STOP_IGNORING_VAR(x)和相應的客戶端請求?VG_USERREQ__DRD_FINISH_SUPPRESSION。告訴DRD不再忽略通過宏DRD_IGNORE_VAR(x)或通過客戶端請求抑制的地址范圍的數據競爭VG_USERREQ__DRD_START_SUPPRESSION。

• 這個宏DRD_TRACE_VAR(x)。追蹤從起始&x和占用sizeof(x)字節開始的地址范圍的所有加載和存儲活動。當DRD在指定的變量上報告數據競爭時，并不立即清楚哪些源代碼語句觸發了沖突的訪問，可能非常有助于跟蹤違規內存位置上的所有活動。

• 這個宏DRD_STOP_TRACING_VAR(x)。停止跟蹤地址范圍的加載和存儲活動，&x并占用sizeof(x)?字節。

• 這個宏ANNOTATE_TRACE_MEMORY(&x)。跟蹤至少觸及地址單個字節的所有加載和存儲活動&x。

• 客戶端請求VG_USERREQ__DRD_START_TRACE_ADDR，允許跟蹤指定地址范圍的所有加載和存儲活動。

• 客戶端請求VG_USERREQ__DRD_STOP_TRACE_ADDR。不再跟蹤指定地址范圍的加載和存儲活動。

• 宏ANNOTATE_HAPPENS_BEFORE(addr)告訴DRD插入一個標記。在執行對指定地址的變量的訪問之后插入此宏。

• 該宏ANNOTATE_HAPPENS_AFTER(addr)告訴DRD，指定地址上的變量的下一次訪問應該被認為是在ANNOTATE_HAPPENS_BEFORE(addr)引用同一變量的最新注釋之前的訪問之后發生的?。這兩個宏的目的是告訴DRD通過原子內存操作實現的線程間內存訪問順序。另見drd/tests/annotate_smart_pointer.cpp一個例子。

• 宏ANNOTATE_RWLOCK_CREATE(rwlock)告訴DRD地址rwlock上的對象是不是pthread_rwlock_t同步對象的讀寫器?同步對象。另見drd/tests/annotate_rwlock.c一個例子。

• 該宏ANNOTATE_RWLOCK_DESTROY(rwlock)告訴DRD地址處的讀寫器同步對象rwlock已被破壞。

• 宏ANNOTATE_WRITERLOCK_ACQUIRED(rwlock)告訴DRD已經在地址處的讀寫器同步對象上獲取了寫入器鎖rwlock。

• 該宏ANNOTATE_READERLOCK_ACQUIRED(rwlock)告訴DRD已經在地址處的讀寫器同步對象上獲取了讀取器鎖定rwlock。

• 宏ANNOTATE_RWLOCK_ACQUIRED(rwlock, is_w)?告訴DRD?在地址處的讀寫器同步對象上已經獲取了寫入器鎖定（何時is_w != 0）或讀取器鎖定（何時is_w == 0）rwlock。

• 宏ANNOTATE_WRITERLOCK_RELEASED(rwlock)告訴DRD地址上的讀寫器同步對象已經釋放了寫入器鎖rwlock。

• 該宏ANNOTATE_READERLOCK_RELEASED(rwlock)告訴DRD在地址處的讀寫器同步對象上已經釋放了讀取器鎖定rwlock。

• 宏ANNOTATE_RWLOCK_RELEASED(rwlock, is_w)?告訴DRD寫入器鎖定（何時is_w != 0）或讀取器鎖定（何時is_w == 0）已在地址處的讀寫器同步對象上釋放rwlock。

• 該宏ANNOTATE_BARRIER_INIT(barrier, count, reinitialization_allowed)告訴DRD，地址處的一個新的屏障對象barrier已被初始化，該count線程參與每個屏障，以及是否將沒有中間破壞的屏障重新初始化作為錯誤報告。另見drd/tests/annotate_barrier.c一個例子。

• 宏ANNOTATE_BARRIER_DESTROY(barrier)?告訴DRD屏障對象即將被銷毀。

• 該宏ANNOTATE_BARRIER_WAIT_BEFORE(barrier)?告訴DRD，等待屏障將開始。

• 宏ANNOTATE_BARRIER_WAIT_AFTER(barrier)?指示DRD等待屏障已經完成。

• 宏ANNOTATE_BENIGN_RACE_SIZED(addr, size, descr)告訴DRD，在指定地址上檢測到的任何種族是良性的，因此不應該報告。該descr參數被忽略，但可用于記錄為什么數據競賽addr是良性的。

• 宏ANNOTATE_BENIGN_RACE_STATIC(var, descr)?告訴DRD，在指定的靜態變量上檢測到的任何種族都是良性的，因此不應該報告。該descr?參數被忽略，但可用于記錄為什么數據競賽var是良性的。注意：這個宏只能在C ++程序中使用，而不能在C程序中使用。

• 宏ANNOTATE_IGNORE_READS_BEGIN告訴DRD忽略當前線程執行的所有內存加載。

• 宏ANNOTATE_IGNORE_READS_END告訴DRD停止忽略當前線程執行的內存負載。

• 宏ANNOTATE_IGNORE_WRITES_BEGIN告訴DRD忽略當前線程執行的所有內存存儲。

• 宏ANNOTATE_IGNORE_WRITES_END告訴DRD停止忽略當前線程執行的內存存儲。

• 宏ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN告訴DRD忽略當前線程執行的所有內存訪問。

• 宏ANNOTATE_IGNORE_READS_AND_WRITES_END告訴DRD停止忽略當前線程執行的內存訪問。

• 該宏ANNOTATE_NEW_MEMORY(addr, size)告訴DRD客戶端程序中的自定義內存分配器分配了指定的內存范圍，并且客戶端程序將開始使用此內存范圍。

• 宏ANNOTATE_THREAD_NAME(name)告訴DRD將指定的名稱與當前線程相關聯，并將此名稱包含在DRD打印的錯誤消息中。

• 宏VALGRIND_MALLOCLIKE_BLOCK和?VALGRIND_FREELIKE_BLOCK從Valgrind核心實現;?它們在?客戶端請求機制中描述。

注意：如果您自己編譯Valgrind，則該命令?<valgrind/drd.h>將頭文件?安裝在目錄中。如果您通過將其安裝為一個包獲得Valgrind，那么您可能必須安裝另一個包含?Valgrind頭文件可用的名稱。?/usr/includemake installvalgrind-devel

8.2.6。調試C ++ 11程序

如果要使用C ++ 11類std :: thread，則需要執行以下操作來注釋在該類的實現中使用的std :: shared_ptr <>對象：

• 在包含任何C ++頭文件之前，在公共頭的起始處或每個源文件的開始添加以下代碼：

  #include <valgrind / drd.h> #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE（addr）ANNOTATE_HAPPENS_BEFORE（addr） #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER（addr）ANNOTATE_HAPPENS_AFTER（addr）

• 下載gcc源代碼，從源文件libstdc ++ - v3 / src / c ++ 11 / thread.cc將執行?execute_native_thread_routine()?和std::thread::_M_start_thread()?函數復制到與應用程序鏈接的源文件中。確保在此源文件中也可以正確定義_GLIBCXX_SYNCHRONIZATION_HAPPENS _ *（）宏。

有關更多信息，請參閱“GNU C ++庫手冊”，“調試支持”?（http://gcc.gnu.org/onlineocs/libstdc++/manual/debug.html）。

8.2.7。調試GNOME程序

GNOME應用程序使用由提供的線程原語?glib和?gthread圖書館。這些庫構建在POSIX線程之上，因此由DRD直接支持。請記住，g_thread_init在創建任何線程之前必須先調用?，否則DRD會報告glib函數上的幾個數據比賽。又見?GLib的參考手冊有關詳細信息?g_thread_init。

glib?圖書館?提供的許多設施之一是一個塊分配器，稱為g_slice。在使用DRD時，必須通過將以下內容添加到shell環境變量來禁用此塊分配器：?G_SLICE=always-malloc。有關更多信息，請參閱GLib參考手冊。

8.2.8。調試Boost.Thread程序

Boost.Thread庫是跨平臺Boost庫附帶的線程庫。這個線程庫是即將推出的C ++ 0x線程庫的早期實現。

使用Boost.Thread庫的應用程序在DRD下運行良好。

有關Boost.Thread的更多信息，請訪問：

• Anthony Williams，Boost.Thread?Library Documentation，Boost website，2007。

• 安東尼·威廉姆斯，Boost Threads的新功能？，最新修改的Boost Thread庫，Dobbs博士，2008年10月。

8.2.9。調試OpenMP程序

OpenMP代表開放多重處理。OpenMP標準包括一組用于C，C ++和Fortran程序的編譯器指令，允許編譯器將順序程序轉換為并行程序。OpenMP非常適合HPC應用程序，并允許在直接使用POSIX線程API的情況下在更高級別工作。雖然OpenMP確保POSIX API被正確使用，但OpenMP程序仍然可以包含數據競爭。因此，使用線程檢查工具驗證OpenMP程序是絕對有意義的。

DRD支持GCC生成的OpenMP共享內存程序。GCC自版本4.2.0起支持OpenMP。GCC對OpenMP程序的運行時支持由一個名為“庫”的庫提供?libgomp。在該庫中實現的同步原語使用Linux'futex系統調用直接，除非該庫已配置該?--disable-linux-futex選項。DRD僅支持已使用此選項配置的libgomp庫，并且其中存在符號信息。對于大多數Linux發行版，這意味著您必須重新編譯GCC。有關drd/scripts/download-and-build-gcc如何編譯GCC的示例，請參閱Valgrind源代碼樹中的腳本?。libgomp.so當OpenMP程序啟動時，您還必須確保新編譯的?庫已加載。

導出LD_LIBRARY_PATH =?/ gcc-4.4.0 / lib64：?/ gcc-4.4.0 / lib：

例如，drd/tests/omp_matinv當在命令行上指定了選項-r時，測試OpenMP測試程序會?觸發數據競爭。數據競賽由以下代碼觸發：

#pragma omp parallel for private（j） for（j = 0; j <rows; j ++） {if（i！= j）{const elem_t factor = a [j * cols + i];for（k = 0; k <cols; k ++）{a [j * cols + k] - = a [i * cols + k] *因子;}} }

上面的代碼是racy，因為變量k沒有被聲明為private。DRD將打印以下代碼的以下錯誤消息：

$ valgrind --tool = drd --check-stack-var = yes --read-var-info = yes drd / tests / omp_matinv 3 -t 2 -r ... 線程1/1在0x7fefffbc4大小的沖突存儲4在0x4014A0：gj.omp_fn.0（omp_matinv.c：203）通過0x401211：gj（omp_matinv.c：159）by 0x40166A：invert_matrix（omp_matinv.c：238）通過0x4019B4：main（omp_matinv.c：316） 位置0x7fefffbc4是本地var“k”內的0個字節 在omp_matinv.c中聲明：160，在線程1的幀＃0中 ...

在上述輸出中，函數名稱gj.omp_fn.0?由GCC從函數名生成?gj。分配上下文信息顯示數據競爭是由修改變量引起的k。

注意：對于4.4.0之前的GCC版本，不顯示分配上下文信息。使用這些GCC版本，上述輸出中最可用的信息是源文件名和檢測到數據競爭的行號（omp_matinv.c:203）。

有關OpenMP的更多信息，另請參閱?openmp.org。

8.2.10。DRD和自定義內存分配器

DRD跟蹤通過標準的內存分配和釋放功能發生的所有內存分配事件（malloc，free，?new和delete），通過進入和已經標注了Valgrind的內存池的客戶端請求的堆棧幀或退出。DRD使用內存分配和釋放信息用于兩個目的：

• 要知道尚未明確銷毀的POSIX對象的范圍結束。例如POSIX線程標準pthread_mutex_destroy在釋放互斥體對象所在的內存之前不需要調用?。

• 要知道變量的范圍在哪里結束。如果一個線程使用了堆內存，該線程將釋放該內存，另一個線程分配并啟動該內存，則不得為該內存報告數據競爭。

DRD的正確操作對工具知道內存分配和釋放事件至關重要。當分析與DRD客戶端程序，使用自定義的內存分配器，無論是儀表自定義的內存分配器與VALGRIND_MALLOCLIKE_BLOCK?和VALGRIND_FREELIKE_BLOCK宏或禁用定制的內存分配器。

例如，GNU libstdc ++庫可以通過設置環境變量來配置為使用標準內存分配函數而不是內存池?GLIBCXX_FORCE_NEW。有關更多信息，另請參閱libstdc ++手冊。

8.2.11。DRD與Memcheck

DRD的正確操作對于客戶機程序中沒有內存錯誤，如懸掛指針是至關重要的。這意味著在使用DRD進行分析之前，確保您的程序是Memcheck-clean是一個好主意。然而，有些Memcheck報告可能是由數據競賽造成的。在這種情況下，在Memcheck之前運行DRD是有意義的。

那么應該先運行哪個工具？如果DRD和Memcheck都抱怨程序，可能的方法是在每次運行每個工具之后交替運行兩個工具并修復盡可能多的錯誤，直到兩個工具都沒有打印任何更多的錯誤消息。

8.2.12。資源要求

DRD對堆棧和堆棧內存的要求以及客戶端程序執行時間的影響如下：

• 在DRD下使用默認DRD選項運行程序時，與客戶端程序的本地運行相比，需要1.1到3.6倍的內存。如果加載了調試信息（--read-var-info=yes），則需要更多的內存。

• DRD在客戶端程序線程的堆棧上分配一些臨時數據結構。此數據量限制在1 - 2 KB。確保線程堆棧足夠大。

• 大多數應用程序在DRD下的運行速度要比本機單線程運行速度慢20到50倍。對于執行頻繁互斥鎖定/解鎖操作的應用程序，減速將最為顯著。

8.2.13。有效使用DRD的提示和提示

使用DRD時，以下信息可能會有所幫助：

• 確保調試信息存在于正在分析的可執行文件中，以便DRD可以在堆棧跟蹤中打印功能名稱和行??號信息。大多數編譯器可以通過編譯器選項來提供調試信息?-g。

• 編譯選項-O1而不是?-O0。這將減少生成的代碼量，可能會減少調試信息的數量，并將加快DRD處理客戶端程序的速度。有關詳細信息，請參閱入門指南。

• 如果DRD報告了作為Linux發行版一部分的庫的任何錯誤，例如，libc.so或者?libstdc++.so安裝這些庫的調試包將使DRD的輸出更加詳細。

• 當使用C ++時，不要將輸出從多個線程發送到?std::cout。這樣做不僅可以生成多個數據競賽報告，還可能導致多個線程的輸出混淆。使用?printf或執行以下操作：

• 派生一個類std::ostreambuf?，讓該類逐行發送輸出?stdout。這將避免不同線程生成的各行文本混淆。

• std::ostream?為每個線程創建一個實例。這使流格式設置線程本地。傳遞從每個實例的構造函數派生的類的每個線程的std::ostreambuf實例。

• 讓每個線程將其輸出發送到自己的實例?std::ostream而不是?std::cout。

8.3。有效地使用POSIX線程API

8.3.1?；コ忸愋?/h3>

單一UNIX規范版本二定義了以下四種互斥體類型（另請參見pthread_mutexattr_settype：文檔）：

• 正常，這意味著不執行錯誤檢查，并且互斥量是非遞歸的。

• 錯誤檢查，這意味著互斥體是非遞歸的，并且執行錯誤檢查。

• 遞歸，這意味著互斥體可能被遞歸鎖定。

• 默認，這意味著錯誤檢查行為是未定義的，并且遞歸鎖定的行為也是未定義的。或者：可移植代碼不能通過Pthreads API觸發錯誤條件，也不得遞歸地鎖定默認類型的互斥體。

在復雜的應用中，事先并不總是清楚地將遞歸鎖定哪些互斥鎖，哪些互斥不會被遞歸地鎖定。嘗試遞歸地鎖定非遞歸互斥將導致在沒有線程檢查工具的情況下很難找到的競爭條件。所以要么使用錯誤檢查互斥體類型，并一直檢查Pthread API互斥調用的返回值，或者使用遞歸互斥體類型。

8.3.2。條件變量

條件變量允許一個線程喚醒一個或多個其他線程。條件變量通常用于通知一個或多個線程關于共享數據的狀態變化。不幸的是，通過使用條件變量作為狀態信息傳播的唯一手段來引入競爭條件是非常容易的。一個更好的方法是讓線程輪詢由互斥體保護的狀態變量的更改，并將條件變量僅用作線程喚醒機制。另請參見源文件?drd/tests/monitor_example.cpp，了解如何在C ++中實現這一概念。該示例中使用的監視器概念是一個眾所周知的非常有用的概念 - 有關監視器?概念的更多信息，另請參見維基百科。

8.3.3。pthread_cond_timedwait和超時

歷史上，該函數?pthread_cond_timedwait僅允許規定絕對超時，這是一個與調用此函數時間無關的超時。但是，幾乎每次調用此函數都表示相對超時。這通常是通過傳遞總和?clock_gettime(CLOCK_REALTIME)和相對超時作為第三個參數。這種方法是不正確的，因為例如ntpd的前向或后向時鐘調整將影響超時。一個更可靠的方法如下：

• 當初始化條件變量時?pthread_cond_init，指定超時?pthread_cond_timedwait將使用時鐘?CLOCK_MONOTONIC而不是?CLOCK_REALTIME。你可以這樣做?pthread_condattr_setclock(..., CLOCK_MONOTONIC)。

• 當調用pthread_cond_timedwait時，將總和?clock_gettime(CLOCK_MONOTONIC)?和相對超時作為第三個參數。

另見?drd/tests/monitor_example.cpp一個例子。

8.4。限制

DRD目前有以下限制：

• DRD就像Memcheck一樣，將拒絕在已經刪除所有符號信息的Linux發行版上啟動?ld.so。這是例如OpenPCS和Gentoo的PPC版本。在使用DRD之前，您必須在這些平臺上安裝glibc debuginfo軟件包。另請參見openSUSE bug?396197和Gentoo bug?214065。

• 使用gcc 4.4.3和之前，DRD可能會std::string在多線程程序中的C ++類上報告數據競爭。這是一個知道的libstdc++問題 - 更多信息，請參閱GCC錯誤?40518?。

• 如果您自己編譯DRD源代碼，則需要GCC 3.0或更高版本。不支持GCC 2.95。

• 在Linux的兩個POSIX線程實現中，只支持NPTL（Native POSIX線程庫）。較舊的LinuxThreads庫不受支持。

8.5。反饋

如果您有關于DRD的任何意見，建議，反饋或錯誤報告，請隨時在Valgrind用戶郵件列表上發布消息或提交錯誤報告。又見http://www.valgrind.org/以獲取更多信息。

總結

以上是生活随笔為你收集整理的DRD：线程错误检测器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。