In .:

2009-02-11  Rodrigo Kumpera  <rkumpera@novell.com>

	* thread-safety.txt: Document the new image lock.

svn path=/trunk/mono/; revision=126667

diff --git a/docs/ChangeLog b/docs/ChangeLog
index 7241365952e737d4aef21d5d986ef31eb7b6f58f..87ccf5c1f39e968f4de51b0619c65a4a701abfcc 100644 (file)
--- a/docs/ChangeLog
+++ b/docs/ChangeLog
@@ -1,3 +1,7 @@
+2009-02-11  Rodrigo Kumpera  <rkumpera@novell.com>
+
+       * thread-safety.txt: Document the new image lock.
+
 2008-12-12  Mark Probst  <mark.probst@gmail.com>
 
        * mini-porting.txt: Added some details about function descriptors

diff --git a/docs/thread-safety.txt b/docs/thread-safety.txt
index 4edf1cd699c3929d11edb79c5a7dc5dde9d11088..b29060506946c02991b3dcbf9acaaa515ba528cf 100644 (file)
--- a/docs/thread-safety.txt
+++ b/docs/thread-safety.txt
@@ -15,7 +15,7 @@ There are three kinds of threads with regards to read-only data:
 
 Most threads are readers.
 
-- synchronization between readers is not neccesary
+- synchronization between readers is not necessary
 - synchronization between the writers is done using locks.
 - synchronization between the readers and the creator is done by not exposing
   the data to readers before it is fully constructed.
@@ -50,7 +50,14 @@ protects the various caches inside MonoImage which are used by these modules.
 
 Each appdomain has a lock which protects the per-domain data structures.
 
-1.3.4 The locking hierarchy
+1.3.4 The image lock
+--------------------
+
+Each MonoImage has a lock which protects the per-image data structures and memory pool. This lock must only
+be held while manipulating such structures and no call to any function besides that should be made. In special,
+no other runtime lock should be acquired while holding an image lock.
+
+1.3.5 The locking hierarchy
 ---------------------------
 
 It is useful to model locks by a locking hierarchy, which is a relation between locks, which is reflexive, transitive,