From c811ed93d3e7b64b3fcf5aab7ac405e0a8d36a59 Mon Sep 17 00:00:00 2001 From: Sebastian Wilhelmi Date: Thu, 8 Mar 2001 09:43:45 +0000 Subject: [PATCH] Spelling corrections. 2001-03-08 Sebastian Wilhelmi * glib/tmpl/threads.sgml: Spelling corrections. --- docs/reference/ChangeLog | 4 ++++ docs/reference/glib/tmpl/threads.sgml | 20 ++++++++++---------- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/docs/reference/ChangeLog b/docs/reference/ChangeLog index bad4c00..1b361d0 100644 --- a/docs/reference/ChangeLog +++ b/docs/reference/ChangeLog @@ -1,3 +1,7 @@ +2001-03-08 Sebastian Wilhelmi + + * glib/tmpl/threads.sgml: Spelling corrections. + Wed Mar 7 15:02:17 2001 Owen Taylor * gobject/Makefile.am: Revert Tim's last commit to diff --git a/docs/reference/glib/tmpl/threads.sgml b/docs/reference/glib/tmpl/threads.sgml index 0d7c16a..2026b20 100644 --- a/docs/reference/glib/tmpl/threads.sgml +++ b/docs/reference/glib/tmpl/threads.sgml @@ -22,7 +22,7 @@ the programmer through synchronization primitives. 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 (#GMutex, #GStaticMutex, #G_LOCK_DEFINE, #GStaticRecMutex and #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 does not necessarily mean, that there is a thread implementation 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. @@ -81,7 +81,7 @@ This macro is defined, if the Solaris thread system is used. 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. @@ -157,7 +157,7 @@ really know, what you are doing. 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(). @@ -403,7 +403,7 @@ access. Take for example the following function: -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 access. A first naive implementation would be: @@ -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 read from, while others also write. In such situations it is 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: @@ -970,11 +970,11 @@ example: 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 readers currently access the array. This is because of the potentially dangerous resizing of the array. Using that functions is fully -multithread safe now. +multi-thread safe now. @@ -987,7 +987,7 @@ the writer will lock it. -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. @@ -1093,7 +1093,7 @@ and can lock @lock for writing. Locks @lock for writing. If @lock is already locked for writing or 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 reading. When @lock is locked for writing, no other thread can lock @lock (neither for reading nor writing). This lock has to be unlocked -- 2.7.4