summaryrefslogtreecommitdiff
path: root/open_issues/locking.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/locking.mdwn')
-rw-r--r--open_issues/locking.mdwn40
1 files changed, 0 insertions, 40 deletions
diff --git a/open_issues/locking.mdwn b/open_issues/locking.mdwn
deleted file mode 100644
index 6e22f887..00000000
--- a/open_issues/locking.mdwn
+++ /dev/null
@@ -1,40 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_hurd gsoc-task]]
-
-Every now and then, new locking issues are discovered in
-[[hurd/libdiskfs]] or [[hurd/translator/ext2fs]], for example. Nowadays
-these in fact seem to be the most often encountered cause of Hurd crashes
-/ lockups.
-
-One of these could be traced
-recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken
-and not released in some cases. There is reason to believe that there are more
-faulty paths causing these lockups.
-
-The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking
-issues. To achieve this, some kind of test harness has to be implemented: For
-example instrumenting the code to check locking correctness constantly at
-runtime. Or implementing a [[unit testing]] framework that explicitly checks
-locking in various code paths. (The latter could serve as a template for
-implementing unit tests in other parts of the Hurd codebase...)
-
-(A [[systematic code review|security]] would probably suffice to find the
-existing locking
-issues; but it wouldn't document the work in terms of actual code produced, and
-thus it's not suitable for a GSoC project...)
-
-This task requires experience with debugging locking issues in
-[[multithreaded|multithreading]] applications.
-
-Tools have been written for automated [[code analysis]]; these can help to
-locate and fix such errors.