luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-04-01 21:33:09 +02:00
Code Issues Packages Projects Releases Wiki Activity

Point out exceptions to the general GLib data structure locking rules.

Browse Source 
2005-05-23  Matthias Clasen  <mclasen@redhat.com>

	* glib/tmpl/threads.sgml: Point out exceptions to the
	general GLib data structure locking rules.
This commit is contained in:
Matthias Clasen 2005-05-23 19:10:54 +00:00 committed by Matthias Clasen
parent 921b8bc1c7
commit d38febf6b3
2 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/reference/ChangeLog
View File

@ -1,3 +1,8 @@
2005-05-23 Matthias Clasen <mclasen@redhat.com>
* glib/tmpl/threads.sgml: Point out exceptions to the
general GLib data structure locking rules.
2005-05-20 Matthias Clasen <mclasen@redhat.com> 2005-05-20 Matthias Clasen <mclasen@redhat.com>
* glib/tmpl/threads.sgml: Add a paragraph about thread * glib/tmpl/threads.sgml: Add a paragraph about thread

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

@ -38,6 +38,9 @@ in a threaded GLib program. After that, GLib is completely thread safe
(all global data is automatically locked). But individual data structure (all global data is automatically locked). But individual data structure
instances are not automatically locked for performance reasons. So e.g. instances are not automatically locked for performance reasons. So e.g.
you must coordinate accesses to the same #GHashTable from multiple threads. you must coordinate accesses to the same #GHashTable from multiple threads.
The two notable exceptions from this rule are #GMainLoop and #GAsyncQueue,
which <emphasis>are</emphasis> threadsafe and needs no further
application-level locking to be accessed from multiple threads.
</para> </para>
<!-- ##### SECTION See_Also ##### --> <!-- ##### SECTION See_Also ##### -->