luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-03-14 19:55:12 +01:00
Code Issues Packages Projects Releases Wiki Activity

Corrected.

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

	* glib/tmpl/threads.sgml (example): Corrected.
This commit is contained in:
Sebastian Wilhelmi 2001-06-26 10:28:48 +00:00 committed by Sebastian Wilhelmi
parent 0646fe7c88
commit 2c9c0fabc8
2 changed files with 8 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/reference/ChangeLog
View File

@ -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.

10
docs/reference/glib/tmpl/threads.sgml
View File

@ -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