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

Spelling corrections.

Browse Source 
2001-03-08  Sebastian Wilhelmi  <wilhelmi@ira.uka.de>

	* glib/tmpl/threads.sgml: Spelling corrections.
This commit is contained in:
Sebastian Wilhelmi
2001-03-08 09:43:45 +00:00
committed by Sebastian Wilhelmi
parent ff42983fb9
commit c811ed93d3
2 changed files with 14 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/reference/ChangeLog
View File

@@ -1,3 +1,7 @@
2001-03-08 Sebastian Wilhelmi <wilhelmi@ira.uka.de>
* glib/tmpl/threads.sgml: Spelling corrections.
Wed Mar 7 15:02:17 2001 Owen Taylor <otaylor@redhat.com> Wed Mar 7 15:02:17 2001 Owen Taylor <otaylor@redhat.com>
* gobject/Makefile.am: Revert Tim's last commit to * gobject/Makefile.am: Revert Tim's last commit to

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

@@ -22,7 +22,7 @@ the programmer through synchronization primitives.
<para> <para>
The aim of the thread related functions in GLib is to provide a The aim of the thread related functions in GLib is to provide a
portable means for writing multithreaded software. There are portable means for writing multi-threaded software. There are
primitives for mutexes to protect the access to portions of memory primitives for mutexes to protect the access to portions of memory
(#GMutex, #GStaticMutex, #G_LOCK_DEFINE, #GStaticRecMutex and (#GMutex, #GStaticMutex, #G_LOCK_DEFINE, #GStaticRecMutex and
#GStaticRWLock), there are primitives for condition variables to allow #GStaticRWLock), there are primitives for condition variables to allow
@@ -55,7 +55,7 @@ primitives to portably create and manage threads (#GThread).
This macro is defined, if GLib was compiled with thread support. This This macro is defined, if GLib was compiled with thread support. This
does not necessarily mean, that there is a thread implementation does not necessarily mean, that there is a thread implementation
available, but the infrastructure is in place and once you provide a available, but the infrastructure is in place and once you provide a
thread implementation to g_thread_init(), GLib will be multithread thread implementation to g_thread_init(), GLib will be multi-thread
safe. It isn't and cannot be, if #G_THREADS_ENABLED is not defined. safe. It isn't and cannot be, if #G_THREADS_ENABLED is not defined.
</para> </para>
@@ -81,7 +81,7 @@ This macro is defined, if the Solaris thread system is used.
<para> <para>
This macro is defined, if no thread implementation is used. You can This macro is defined, if no thread implementation is used. You can
however provide one to g_thread_init() to make GLib multithread safe. however provide one to g_thread_init() to make GLib multi-thread safe.
</para> </para>
@@ -157,7 +157,7 @@ really know, what you are doing.
<note> <note>
<para> <para>
g_thread_init() must not be called directly or indirectly as a g_thread_init() must not be called directly or indirectly as a
callback from GLib. Also no mutexes may be currently locked, while call-back from GLib. Also no mutexes may be currently locked, while
calling g_thread_init(). calling g_thread_init().
</para> </para>
</note> </note>
@@ -403,7 +403,7 @@ access. Take for example the following function:
</para> </para>
<para> <para>
It is easy to see, that this won't work in a multithreaded It is easy to see, that this won't work in a multi-threaded
application. There current_number must be protected against shared application. There current_number must be protected against shared
access. A first naive implementation would be: access. A first naive implementation would be:
</para> </para>
@@ -923,7 +923,7 @@ The #GStaticRWLock struct represents a read-write lock. A read-write
lock can be used for protecting data, that some portions of code only lock can be used for protecting data, that some portions of code only
read from, while others also write. In such situations it is read from, while others also write. In such situations it is
desirable, that several readers can read at once, whereas of course desirable, that several readers can read at once, whereas of course
only one writer may write at a time. Take a look at the followin only one writer may write at a time. Take a look at the following
example: example:
<example> <example>
@@ -970,11 +970,11 @@ example:
<para> <para>
This example shows an array, which can be accessed by many readers This example shows an array, which can be accessed by many readers
(the my_array_get function) simultaniously, whereas the writers (the (the my_array_get function) simultaneously, whereas the writers (the
my_array_set function) only will be allowed once a time and only if no my_array_set function) only will be allowed once a time and only if no
readers currently access the array. This is because of the potentially readers currently access the array. This is because of the potentially
dangerous resizing of the array. Using that functions is fully dangerous resizing of the array. Using that functions is fully
multithread safe now. multi-thread safe now.
</para> </para>
<para> <para>
@@ -987,7 +987,7 @@ the writer will lock it.
</para> </para>
<para> <para>
Even though #GStaticRWLoc is not opaque, it should only be used with Even though #GStaticRWLock is not opaque, it should only be used with
the following functions. the following functions.
</para> </para>
@@ -1093,7 +1093,7 @@ and can lock @lock for writing.
<para> <para>
Locks @lock for writing. If @lock is already locked for writing or Locks @lock for writing. If @lock is already locked for writing or
reading by other threads, this function will block until @lock is reading by other threads, this function will block until @lock is
completly unlocked and then lock @lock for writing. While this completely unlocked and then lock @lock for writing. While this
functions waits to lock @lock, no other thread can lock @lock for functions waits to lock @lock, no other thread can lock @lock for
reading. When @lock is locked for writing, no other thread can lock reading. When @lock is locked for writing, no other thread can lock
@lock (neither for reading nor writing). This lock has to be unlocked @lock (neither for reading nor writing). This lock has to be unlocked