X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=glib%2Fgthread.c;h=ea8e5f9656f55945bb365f645e25dee26b61ed6b;hb=7e3d32b7053b47ca7feecf185abac96b619770c2;hp=ffac638a15fc0aab2dbce68cddcc04b6eb2a865c;hpb=4d12e0d66f1641a6eb2ba9c65579935136f6ef46;p=platform%2Fupstream%2Fglib.git diff --git a/glib/gthread.c b/glib/gthread.c index ffac638..ea8e5f9 100644 --- a/glib/gthread.c +++ b/glib/gthread.c @@ -100,44 +100,37 @@ * Originally, UNIX did not have threads, and therefore some traditional * UNIX APIs are problematic in threaded programs. Some notable examples * are - * - * - * C library functions that return data in statically allocated - * buffers, such as strtok() or strerror(). For many of these, - * there are thread-safe variants with a _r suffix, or you can - * look at corresponding GLib APIs (like g_strsplit() or g_strerror()). - * - * - * setenv() and unsetenv() manipulate the process environment in - * a not thread-safe way, and may interfere with getenv() calls - * in other threads. Note that getenv() calls may be - * hidden behind other APIs. For example, GNU gettext() - * calls getenv() under the covers. In general, it is best to treat - * the environment as readonly. If you absolutely have to modify the - * environment, do it early in main(), when no other threads are around yet. - * - * - * setlocale() changes the locale for the entire process, affecting - * all threads. Temporary changes to the locale are often made to - * change the behavior of string scanning or formatting functions - * like scanf() or printf(). GLib offers a number of string APIs - * (like g_ascii_formatd() or g_ascii_strtod()) that can often be - * used as an alternative. Or you can use the uselocale() function - * to change the locale only for the current thread. - * - * - * fork() only takes the calling thread into the child's copy of the - * process image. If other threads were executing in critical - * sections they could have left mutexes locked which could easily - * cause deadlocks in the new child. For this reason, you should - * call exit() or exec() as soon as possible in the child and only - * make signal-safe library calls before that. - * - * - * daemon() uses fork() in a way contrary to what is described - * above. It should not be used with GLib programs. - * - * + * + * - C library functions that return data in statically allocated + * buffers, such as strtok() or strerror(). For many of these, + * there are thread-safe variants with a _r suffix, or you can + * look at corresponding GLib APIs (like g_strsplit() or g_strerror()). + * + * - The functions setenv() and unsetenv() manipulate the process + * environment in a not thread-safe way, and may interfere with getenv() + * calls in other threads. Note that getenv() calls may be hidden behind + * other APIs. For example, GNU gettext() calls getenv() under the + * covers. In general, it is best to treat the environment as readonly. + * If you absolutely have to modify the environment, do it early in + * main(), when no other threads are around yet. + * + * - The setlocale() function changes the locale for the entire process, + * affecting all threads. Temporary changes to the locale are often made + * to change the behavior of string scanning or formatting functions + * like scanf() or printf(). GLib offers a number of string APIs + * (like g_ascii_formatd() or g_ascii_strtod()) that can often be + * used as an alternative. Or you can use the uselocale() function + * to change the locale only for the current thread. + * + * - The fork() function only takes the calling thread into the child's + * copy of the process image. If other threads were executing in critical + * sections they could have left mutexes locked which could easily + * cause deadlocks in the new child. For this reason, you should + * call exit() or exec() as soon as possible in the child and only + * make signal-safe library calls before that. + * + * - The daemon() function uses fork() in a way contrary to what is + * described above. It should not be used with GLib programs. * * GLib itself is internally completely thread-safe (all global data is * automatically locked), but individual data structure instances are @@ -155,19 +148,17 @@ * G_LOCK_DEFINE: * @name: the name of the lock * - * The G_LOCK_* macros provide a convenient interface to #GMutex. + * The #G_LOCK_ macros provide a convenient interface to #GMutex. * #G_LOCK_DEFINE defines a lock. It can appear in any place where * variable definitions may appear in programs, i.e. in the first block * of a function or outside of functions. The @name parameter will be * mangled to get the name of the #GMutex. This means that you * can use names of existing variables as the parameter - e.g. the name * of the variable you intend to protect with the lock. Look at our - * give_me_next_number() example using the - * G_LOCK_* macros: + * give_me_next_number() example using the #G_LOCK macros: * - * - * Using the <literal>G_LOCK_*</literal> convenience macros - * + * Here is an example for using the #G_LOCK convenience macros: + * |[ * G_LOCK_DEFINE (current_number); * * int @@ -182,8 +173,7 @@ * * return ret_val; * } - * - * + * ]| */ /** @@ -234,33 +224,26 @@ * * The #GMutex struct is an opaque data structure to represent a mutex * (mutual exclusion). It can be used to protect data against shared - * access. Take for example the following function: + * access. * - * - * A function which will not work in a threaded environment - * + * Take for example the following function: + * |[ * int * give_me_next_number (void) * { * static int current_number = 0; * - * /* now do a very complicated calculation to calculate the new - * * number, this might for example be a random number generator - * */ + * // now do a very complicated calculation to calculate the new + * // number, this might for example be a random number generator * current_number = calc_next_number (current_number); * * return current_number; * } - * - * - * + * ]| * 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 #GMutex can be used as a solution to this problem: - * - * - * Using GMutex to protected a shared variable - * + * |[ * int * give_me_next_number (void) * { @@ -268,15 +251,13 @@ * static int current_number = 0; * int ret_val; * - * g_mutex_lock (&mutex); + * g_mutex_lock (&mutex); * ret_val = current_number = calc_next_number (current_number); - * g_mutex_unlock (&mutex); + * g_mutex_unlock (&mutex); * * return ret_val; * } - * - * - * + * ]| * Notice that the #GMutex is not initialised to any particular value. * Its placement in static storage ensures that it will be initialised * to all-zeros, which is appropriate. @@ -284,8 +265,7 @@ * If a #GMutex is placed in other contexts (eg: embedded in a struct) * then it must be explicitly initialised using g_mutex_init(). * - * A #GMutex should only be accessed via g_mutex_ - * functions. + * A #GMutex should only be accessed via g_mutex_ functions. */ /* GRecMutex Documentation {{{1 -------------------------------------- */ @@ -304,7 +284,7 @@ * g_rec_mutex_init() on it and g_rec_mutex_clear() when done. * * A GRecMutex should only be accessed with the - * g_rec_mutex_ functions. + * g_rec_mutex_ functions. * * Since: 2.32 */ @@ -325,9 +305,8 @@ * simultaneous read-only access (by holding the 'reader' lock via * g_rw_lock_reader_lock()). * - * - * An array with access functions - * + * Here is an example for an array with access functions: + * |[ * GRWLock lock; * GPtrArray *array; * @@ -339,10 +318,10 @@ * if (!array) * return NULL; * - * g_rw_lock_reader_lock (&lock); - * if (index < array->len) + * g_rw_lock_reader_lock (&lock); + * if (index < array->len) * retval = g_ptr_array_index (array, index); - * g_rw_lock_reader_unlock (&lock); + * g_rw_lock_reader_unlock (&lock); * * return retval; * } @@ -350,35 +329,30 @@ * void * my_array_set (guint index, gpointer data) * { - * g_rw_lock_writer_lock (&lock); + * g_rw_lock_writer_lock (&lock); * * if (!array) - * array = g_ptr_array_new (); + * array = g_ptr_array_new (); * * if (index >= array->len) * g_ptr_array_set_size (array, index+1); * g_ptr_array_index (array, index) = data; * - * g_rw_lock_writer_unlock (&lock); + * g_rw_lock_writer_unlock (&lock); * } - * - * - * This example shows an array which can be accessed by many readers - * (the my_array_get() function) simultaneously, - * whereas the writers (the my_array_set() - * function) will only be allowed once at a time and only if no readers - * currently access the array. This is because of the potentially - * dangerous resizing of the array. Using these functions is fully - * multi-thread safe now. - * - * + * ]| + * This example shows an array which can be accessed by many readers + * (the my_array_get() function) simultaneously, whereas the writers + * (the my_array_set() function) will only be allowed one at a time + * and only if no readers currently access the array. This is because + * of the potentially dangerous resizing of the array. Using these + * functions is fully multi-thread safe now. * * If a #GRWLock is allocated in static storage then it can be used * without initialisation. Otherwise, you should call * g_rw_lock_init() on it and g_rw_lock_clear() when done. * - * A GRWLock should only be accessed with the - * g_rw_lock_ functions. + * A GRWLock should only be accessed with the g_rw_lock_ functions. * * Since: 2.32 */ @@ -399,11 +373,9 @@ * another thread publishes the data, it can signal one of the waiting * threads to wake up to collect the data. * - * - * - * Using GCond to block a thread until a condition is satisfied - * - * + * Here is an example for using GCond to block a thread until a condition + * is satisfied: + * |[ * gpointer current_data = NULL; * GMutex data_mutex; * GCond data_cond; @@ -431,21 +403,19 @@ * * return data; * } - * - * - * + * ]| * Whenever a thread calls pop_data() now, it will wait until * current_data is non-%NULL, i.e. until some other thread * has called push_data(). * * The example shows that use of a condition variable must always be * paired with a mutex. Without the use of a mutex, there would be a - * race between the check of current_data by the - * while loop in pop_data and waiting. - * Specifically, another thread could set pop_data - * after the check, and signal the cond (with nobody waiting on it) - * before the first thread goes to sleep. #GCond is specifically useful - * for its ability to release the mutex and go to sleep atomically. + * race between the check of @current_data by the while loop in + * pop_data() and waiting. Specifically, another thread could set + * @current_data after the check, and signal the cond (with nobody + * waiting on it) before the first thread goes to sleep. #GCond is + * specifically useful for its ability to release the mutex and go + * to sleep atomically. * * It is also important to use the g_cond_wait() and g_cond_wait_until() * functions only inside a loop which checks for the condition to be @@ -453,11 +423,10 @@ * not be true even after it returns. * * If a #GCond is allocated in static storage then it can be used - * without initialisation. Otherwise, you should call g_cond_init() on - * it and g_cond_clear() when done. + * without initialisation. Otherwise, you should call g_cond_init() + * on it and g_cond_clear() when done. * - * A #GCond should only be accessed via the g_cond_ - * functions. + * A #GCond should only be accessed via the g_cond_ functions. */ /* GThread Documentation {{{1 ---------------------------------------- */ @@ -467,7 +436,7 @@ * * The #GThread struct represents a running thread. This struct * is returned by g_thread_new() or g_thread_try_new(). You can - * obtain the #GThread struct representing the current thead by + * obtain the #GThread struct representing the current thread by * calling g_thread_self(). * * GThread is refcounted, see g_thread_ref() and g_thread_unref(). @@ -549,7 +518,7 @@ G_LOCK_DEFINE_STATIC (g_thread_new); * * A #GOnce must be initialized with this macro before it can be used. * - * |[ + * |[ * GOnce my_once = G_ONCE_INIT; * ]| * @@ -589,7 +558,7 @@ G_LOCK_DEFINE_STATIC (g_thread_new); * Calling g_once() recursively on the same #GOnce struct in * @func will lead to a deadlock. * - * |[ + * |[ * gpointer * get_debug_flags (void) * { @@ -644,17 +613,17 @@ g_once_impl (GOnce *once, * blocked until initialization completed. To be used in constructs * like this: * - * |[ + * |[ * static gsize initialization_value = 0; * - * if (g_once_init_enter (&initialization_value)) + * if (g_once_init_enter (&initialization_value)) * { - * gsize setup_value = 42; /** initialization code here **/ + * gsize setup_value = 42; // initialization code here * - * g_once_init_leave (&initialization_value, setup_value); + * g_once_init_leave (&initialization_value, setup_value); * } * - * /** use initialization_value here **/ + * // use initialization_value here * ]| * * Returns: %TRUE if the initialization section should be entered, @@ -903,11 +872,11 @@ g_thread_new_internal (const gchar *name, * waiting thread will be woken up and get @retval as the return value * of g_thread_join(). * - * Calling g_thread_exit (retval) is equivalent to + * Calling g_thread_exit() with a parameter @retval is equivalent to * returning @retval from the function @func, as given to g_thread_new(). * * You must only call g_thread_exit() from a thread that you created - * yourself with g_thread_new() or related APIs. You must not call + * yourself with g_thread_new() or related APIs. You must not call * this function from a thread created with another threading library * or or from within a #GThreadPool. */