<commit_before>/* GLIB - Library of useful routines for C programming
 * Copyright (C) 1995-1997  <NAME>, <NAME> and <NAME>
 *
 * gthread.c: MT safety related functions
 * Copyright 1998 <NAME>; University of Karlsruhe
 *                <NAME>
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the
 * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 * Boston, MA 02111-1307, USA.
 */

/* Prelude {{{1 ----------------------------------------------------------- */

/*
 * Modified by the GLib Team and others 1997-2000.  See the AUTHORS
 * file for a list of people on the GLib Team.  See the ChangeLog
 * files for a list of changes.  These files are distributed with
 * GLib at ftp://ftp.gtk.org/pub/gtk/.
 */

/*
 * MT safe
 */

/* implement gthread.h's inline functions */
#define G_IMPLEMENT_INLINES 1
#define __G_THREAD_C__

#include "config.h"

#include "gthread.h"
#include "gthreadprivate.h"

#include <string.h>

#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif

#ifndef G_OS_WIN32
#include <sys/time.h>
#include <time.h>
#else
#include <windows.h>
#endif /* G_OS_WIN32 */

#include "gslice.h"
#include "gtestutils.h"

/**
 * SECTION:threads
 * @title: Threads
 * @short_description: portable support for threads, mutexes, locks,
 *     conditions and thread private data
 * @see_also: #GThreadPool, #GAsyncQueue
 *
 * Threads act almost like processes, but unlike processes all threads
 * of one process share the same memory. This is good, as it provides
 * easy communication between the involved threads via this shared
 * memory, and it is bad, because strange things (so called
 * "Heisenbugs") might happen if the program is not carefully designed.
 * In particular, due to the concurrent nature of threads, no
 * assumptions on the order of execution of code running in different
 * threads can be made, unless order is explicitly forced by the
 * programmer through synchronization primitives.
 *
 * The aim of the thread-related functions in GLib is to provide a
 * portable means for writing multi-threaded software. There are
 * primitives for mutexes to protect the access to portions of memory
 * (#GMutex, #GRecMutex and #GRWLock). There is a facility to use
 * individual bits for locks (g_bit_lock()). There are primitives
 * for condition variables to allow synchronization of threads (#GCond).
 * There are primitives for thread-private data - data that every
 * thread has a private instance of (#GPrivate). There are facilities
 * for one-time initialization (#GOnce, g_once_init_enter()). Finally,
 * there are primitives to create and manage threads (#GThread).
 *
 * The GLib threading system used to be initialized with g_thread_init().
 * This is no longer necessary. Since version 2.32, the GLib threading
 * system is automatically initialized at the start of your program,
 * and all thread-creation functions and synchronization primitives
 * are available right away.
 *
 * Note that it is not safe to assume that your program has no threads
 * even if you don't call g_thread_new() yourself. GLib and GIO can
 * and will create threads for their own purposes in some cases, such
 * as when using g_unix_signal_source_new() or when using #GDBus.
 *
 * Originally, UNIX did not have threads, and therefore some traditional
 * UNIX APIs are problematic in threaded programs. Some notable examples
 * are
 * <itemizedlist>
 *   <listitem>
 *     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()).
 *   </listitem>
 *   <listitem>
 *     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
 *     <quote>hidden</quote> 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.
 *   </listitem>
 *   <listitem>
 *     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.
 *   </listitem>
 * </itemizedlist>
 *
 * GLib itself is internally completely thread-safe (all global data is
 * automatically locked), but individual data structure instances are
 * not automatically locked for performance reasons. For example,
 * 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> thread-safe and
 * need no further application-level locking to be accessed from
 * multiple threads. Most refcounting functions such as g_object_ref()
 * are also thread-safe.
 */

/* G_LOCK Documentation {{{1 ---------------------------------------------- */

/**
 * G_LOCK_DEFINE:<commit_msg>Add to the pitfalls: fork() and daemon()<commit_after>/* GLIB - Library of useful routines for C programming
 * Copyright (C) 1995-1997  <NAME>, <NAME> and <NAME>
 *
 * gthread.c: MT safety related functions
 * Copyright 1998 <NAME>; University of Karlsruhe
 *                <NAME>
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the
 * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 * Boston, MA 02111-1307, USA.
 */

/* Prelude {{{1 ----------------------------------------------------------- */

/*
 * Modified by the GLib Team and others 1997-2000.  See the AUTHORS
 * file for a list of people on the GLib Team.  See the ChangeLog
 * files for a list of changes.  These files are distributed with
 * GLib at ftp://ftp.gtk.org/pub/gtk/.
 */

/*
 * MT safe
 */

/* implement gthread.h's inline functions */
#define G_IMPLEMENT_INLINES 1
#define __G_THREAD_C__

#include "config.h"

#include "gthread.h"
#include "gthreadprivate.h"

#include <string.h>

#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif

#ifndef G_OS_WIN32
#include <sys/time.h>
#include <time.h>
#else
#include <windows.h>
#endif /* G_OS_WIN32 */

#include "gslice.h"
#include "gtestutils.h"

/**
 * SECTION:threads
 * @title: Threads
 * @short_description: portable support for threads, mutexes, locks,
 *     conditions and thread private data
 * @see_also: #GThreadPool, #GAsyncQueue
 *
 * Threads act almost like processes, but unlike processes all threads
 * of one process share the same memory. This is good, as it provides
 * easy communication between the involved threads via this shared
 * memory, and it is bad, because strange things (so called
 * "Heisenbugs") might happen if the program is not carefully designed.
 * In particular, due to the concurrent nature of threads, no
 * assumptions on the order of execution of code running in different
 * threads can be made, unless order is explicitly forced by the
 * programmer through synchronization primitives.
 *
 * The aim of the thread-related functions in GLib is to provide a
 * portable means for writing multi-threaded software. There are
 * primitives for mutexes to protect the access to portions of memory
 * (#GMutex, #GRecMutex and #GRWLock). There is a facility to use
 * individual bits for locks (g_bit_lock()). There are primitives
 * for condition variables to allow synchronization of threads (#GCond).
 * There are primitives for thread-private data - data that every
 * thread has a private instance of (#GPrivate). There are facilities
 * for one-time initialization (#GOnce, g_once_init_enter()). Finally,
 * there are primitives to create and manage threads (#GThread).
 *
 * The GLib threading system used to be initialized with g_thread_init().
 * This is no longer necessary. Since version 2.32, the GLib threading
 * system is automatically initialized at the start of your program,
 * and all thread-creation functions and synchronization primitives
 * are available right away.
 *
 * Note that it is not safe to assume that your program has no threads
 * even if you don't call g_thread_new() yourself. GLib and GIO can
 * and will create threads for their own purposes in some cases, such
 * as when using g_unix_signal_source_new() or when using #GDBus.
 *
 * Originally, UNIX did not have threads, and therefore some traditional
 * UNIX APIs are problematic in threaded programs. Some notable examples
 * are
 * <itemizedlist>
 *   <listitem>
 *     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()).
 *   </listitem>
 *   <listitem>
 *     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
 *     <quote>hidden</quote> 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.
 *   </listitem>
 *   <listitem>
 *     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.
 *   </listitem>
 *   <listitem>
 *     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.
 *   </listitem>
 *   <listitem>
 *     daemon() uses fork() in a way contrary to what is described
 *     above.  It should not be used with GLib programs.
 *   </listitem>
 * </itemizedlist>
 *
 * GLib itself is internally completely thread-safe (all global data is
 * automatically locked), but individual data structure instances are
 * not automatically locked for performance reasons. For example,
 * 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> thread-safe and
 * need no further application-level locking to be accessed from
 * multiple threads. Most refcounting functions such as g_object_ref()
 * are also thread-safe.
 */

/* G_LOCK Documentation {{{1 ---------------------------------------------- */

/**
 * G_LOCK_DEFINE:
{'fraction_non_alphanumeric': 0.09044314776849077, 'fraction_numerical': 0.007096672449140514, 'mean_word_length': 3.426876090750436, 'pattern_counts': {'":': 0, '<': 51, '<?xml version=': 0, '>': 51, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4067259', 'n_tokens_mistral': 3470, 'n_tokens_neox': 3316, 'n_words': 1672}