[FFmpeg-devel] [PATCH] web/index: mention brute-force thread-debugging article

[Lou Logan]

---
 src/index | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/src/index b/src/index
index b666d40..5c244dc 100644
--- a/src/index
+++ b/src/index
@@ -12,6 +12,38 @@ changes.
 <img src="gplus-16.png" alt="Google+" style="vertical-align: middle; margin-left: 16px"/></a></h1>
 
 
+<a id="thread_debugging"></a><h3>January 12, 2014, Thread-debugging and Heisenbugs</h3>
+<p>
+FFmpeg developer Ronald S. Bultje has written an interesting article,
+<a href="http://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/">
+Brute-force thread-debugging</a>:
+</p>
+
+<blockquote>
+<p>
+"Thread debugging should be easy; there’s advanced tools like helgrind
+and chess, so it’s a solved problem, right?
+</p>
+<p>
+Once upon a time, FFmpeg merged the mt-branch, which allowed
+frame-level multi-threading. While one CPU core decodes frame 1, the
+next CPU core will decode frame 2 in parallel (and so on for any other
+CPU cores you have). This might sound somewhat odd, because don’t most
+video codecs use motion vectors to access data in previously coded
+reference frames? Yes, they do, but we can simply add a condition
+variable so that thread 2 waits for the relevant data in the reference
+frame (concurrently decoded by thread 1) to have finished reconstructing
+that data, and all works fine. Although this might seem to destroy the
+whole point of concurrency, it works well in practice (because motion
+vectors tend to not cross a whole frame)."
+</p>
+</blockquote>
+
+<p>
+<a href="http://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/">Read more</a>
+at Ronald's blog.
+</p>
+
 <a id="ffmpeg_rfp"></a><h3>November 12, 2013, FFmpeg RFP in Debian</h3>
 <p>
 Since the splitting of Libav the Debian/Ubuntu maintainers have followed
-- 
1.8.5.2