Commit 2c9c0fab authored by Sebastian Wilhelmi's avatar Sebastian Wilhelmi Committed by Sebastian Wilhelmi

Corrected.


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

	* glib/tmpl/threads.sgml (example): Corrected.
parent 0646fe7c
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.
......
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment