From 2c9c0fabc8376a336cde4defa67b9b751954ea87 Mon Sep 17 00:00:00 2001 From: Sebastian Wilhelmi Date: Tue, 26 Jun 2001 10:28:48 +0000 Subject: [PATCH] Corrected. 2001-06-26 Sebastian Wilhelmi * glib/tmpl/threads.sgml (example): Corrected. --- docs/reference/ChangeLog | 4 ++++ docs/reference/glib/tmpl/threads.sgml | 10 ++++------ 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/reference/ChangeLog b/docs/reference/ChangeLog index 296467836..f24185b18 100644 --- a/docs/reference/ChangeLog +++ b/docs/reference/ChangeLog @@ -1,3 +1,7 @@ +2001-06-26 Sebastian Wilhelmi + + * glib/tmpl/threads.sgml (example): Corrected. + 2001-06-07 Sebastian Wilhelmi * 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 80f2c7141..dc77f726e 100644 --- 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. 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(). -#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. @lock: a #GStaticRWLock to lock for reading