Corrected.

2001-06-26  Sebastian Wilhelmi  <wilhelmi@ira.uka.de>

	* glib/tmpl/threads.sgml (example): Corrected.

diff --git a/docs/reference/ChangeLog b/docs/reference/ChangeLog
index 29646783658be047b3061585b8923d4c7d175385..f24185b18f05edc27194b1ddae8a2a23cc5d780b 100644 (file)
--- a/docs/reference/ChangeLog
+++ b/docs/reference/ChangeLog
@@ -1,3 +1,7 @@
+2001-06-26  Sebastian Wilhelmi  <wilhelmi@ira.uka.de>
+
+       * glib/tmpl/threads.sgml (example): Corrected.
+
 2001-06-07  Sebastian Wilhelmi  <wilhelmi@ira.uka.de>
 
        * glib/glib-sections.txt, glib/tmpl/date.sgml: Add g_time_val_add.

diff --git a/docs/reference/glib/tmpl/threads.sgml b/docs/reference/glib/tmpl/threads.sgml
index 80f2c7141e47bbf9da5efb292ca89b06a36c32ee..dc77f726e0dd80faec67f1d48de31ef178389c0c 100644 (file)
--- a/docs/reference/glib/tmpl/threads.sgml
+++ b/docs/reference/glib/tmpl/threads.sgml
@@ -1078,7 +1078,7 @@ g_thread_init() has not been called.
 <para>
 A read-write lock has a higher overhead as a mutex. For example both
 g_static_rw_lock_reader_lock() and g_static_rw_lock_reader_unlock()
-has to lock and unlock a #GStaticMutex, so it takes at least twice the
+have to lock and unlock a #GStaticMutex, so it takes at least twice the
 time to lock and unlock a #GStaticRWLock than to lock and unlock a
 #GStaticMutex. So only data structures, that are accessed by multiple
 readers, which keep the lock for a considerable time justify a
@@ -1134,11 +1134,9 @@ g_static_rw_lock_reader_unlock().
 </para>
 
 <para>
-#GStaticRWLock in general is not recursive, but as there may be
-unlimited concurrent locks for reading, it effectively is for
-recursive for reading, but for reading only. Locking for writing after
-locking for reading will deadlock, the same holds true for the
-opposite order.
+#GStaticRWLock is not recursive. It might seem to be possible to
+recursivly lock for reading, but that can result in a deadlock as
+well, due to writer preference.
 </para>
 
 @lock: a #GStaticRWLock to lock for reading