The return value from `g_cond_wait_until()` is calculated, based on the
value of `errno` after reacquiring the mutex. This is a problem because
`errno` can be overwritten in the case the mutex is contended (in which
case the slow-path code will re-enter the kernel).
Perform the calculation before reacquiring the mutex.
See merge request GNOME/glib!958
The documentation erroneously said that a thread calling
g_rw_lock_reader_lock() would always block if another thread was waiting
for the write lock. That’s not true: if no thread holds the lock, it is
implementation defined which of a waiting reader and writer gets the
lock.
See
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_rwlock_rdlock.html.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #590
In file included from glib/glibconfig.h:9,
from glib/gtypes.h:32,
from glib/gatomic.h:27,
from glib/gthread.h:32,
from glib/gthread-posix.c:42:
glib/gthread-posix.c: In function ‘g_system_thread_new’:
glib/gmacros.h:348:26: error: comparison of integer expressions of different signedness: ‘long int’ and ‘gulong’ {aka ‘long unsigned int’} [-Werror=sign-compare]
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
^
glib/gthread-posix.c:1169:22: note: in expansion of macro ‘MAX’
stack_size = MAX (min_stack_size, stack_size);
^~~
glib/gmacros.h:348:35: error: operand of ?: changes signedness from ‘long int’ to ‘gulong’ {aka ‘long unsigned int’} due to unsignedness of other operand [-Werror=sign-compare]
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
^~~
glib/gthread-posix.c:1169:22: note: in expansion of macro ‘MAX’
stack_size = MAX (min_stack_size, stack_size);
^~~
This code was a persistent source of `-fsanitize=thread` errors
when I was trying to use it on OSTree.
The problem is that while I think this code is functionally correct,
we hold a mutex during the writes, but not the reads, and TSAN (IMO
correctly) flags that.
Reading this, I don't see a reason we need a mutex at all. At the
cost of some small code duplication between posix/win32, we can just
pass the data we need down into each implementation. This ends up
being notably cleaner I think than the awkward "lock/unlock to
serialize" dance.
(Minor review changes made by Philip Withnall <withnall@endlessm.com>.)
https://gitlab.gnome.org/GNOME/glib/issues/1224
This seems to have been present since the code was introduced in commit
cedc82290f860683d695d0c5326db153893eec21. The attr variable is defined
under one #ifdef, but destroyed under another, which doesn’t make any
sense. The second #ifdef variable is actually an enum value, rather than
the static initialiser value which makes more sense in the context.
Note that GMutex used to be statically initialised to the value of
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP in gthread.h, before this was
reworked in commit e081eadda598bc708fbf9dd53a190fc3b0e7fa76.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793026
It can only fail if there’s been a leak or programmer error, so this is
really unlikely to happen. At least make it obvious something has gone
wrong, though, rather than silently carrying on and returning as if the
reader lock has been acquired.
Do the same for g_rw_lock_writer_lock().
It should be safe to use g_critical() for reporting the problems, since
GRWLock is not used in gmessages.c, and printing a critical seems better
than aborting, just in case we do hit the ‘maximum number of reader
locks’ error code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756430
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
We now prefer pthread_setname_np when available, and don't
need the linux specific API anymore. Also change the test
for this functionality to use pthread_getname_np.
Detect the following two errors:
- attempting to unlock a mutex that is not locked
- attempting to clear a mutex that was not initialised or was
initialised but is still locked
Both of these are fatal errors. We avoid using g_error() here because
doing so would involve calls back into the GMutex code, and if things
are going off the rails then we want to avoid that.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
If we have futex(2) then we can implement GMutex natively and gain a
substantial performance increase (vs. using pthreads).
This also avoids the need to allocate an extra structure in memory when
using GMutex or GCond: we can use the structure directly.
The main reason for the increase in performance is that our
implementation can be made more simple: we don't need to support the
array of options on pthread_mutex_t (which includes the possibility, for
example, of being recursive).
The result is a ~30% improvement in uncontended cases and a much larger
increase (3 to 4 times) in contended cases for a simple testcase.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
Give compiler a hint that these should be inlined,
which doesn't seem to happen by default with -O2.
Yields 5% speedup in artificial benchmarks, and
1% speedup in a real-world test case doing a lot
of mutex locking and unlocking.
https://bugzilla.gnome.org/show_bug.cgi?id=730807
Make sure this call succeeds, aborting if it doesn't
This will prevent people from having to waste time chasing down the problems
that would otherwise be caused by this silent failure.
We've had a relatively rocky path with g_cond_wait_until() on systems
that either don't support pthread_condattr_setclock() or where
g_get_monotonic_time() is not based on CLOCK_MONOTONIC (ie: Android and
Mac OS).
Fortunately, both of these platforms seem to share
pthread_cond_timedwait_relative_np() which allows us to implement
g_cond_wait_until() without races.
With this patch, we now require that one of pthread_condattr_setclock()
or pthread_cond_timedwait_relative_np() exists. A quick look around
suggests that this is true for all platforms that we care about.
This patch removes our use of pthread_cond_timedwait_monotonic() and
pthread_cond_timedwait_monotonic_np() which were Android-only APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=673607
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Otherwise we have to rely on pthread_cond_timedwait() actually using
the monotonic clock, which might be true or not. On Android at least
it is using the realtime clock, no pthread_condattr_setclock() is available
but instead pthread_cond_timedwait_monotonic() can be used.
This reverts commits dfbac178bdcbcb042be928dcbeaa87742b511836 and
56348210f38209a11902e54b2db41833aab36414.
These two commits introduce undesirable behaviour and were made with no
apparent approval from anybody at all, and without reference to a bug or
mailing list discussion.
In order to fully undo the effects of g_mutex_init(),
it is necessary to reset the internal mutex pointer
back to NULL so that a later call to g_mutex_init()
actually works as expected.
On platforms where dependent loads can be reordered (alpha) and we have
exotic implementation of pthread_mutex_lock() it could be possible that
our implementation of g_mutex_lock() is unsafe.
Always use atomic operations to avoid this possibility.
https://bugzilla.gnome.org/show_bug.cgi?id=686191
g_thread_init() has done nothing since 2.32, so while the function
still can be used if "g_thread_init() has not yet been called",
it won't do nothing in that case, it will just perform normally.
Switch GCond to using monotonic time for timed waits by introducing a
new API based on monotonic time in a gint64: g_cond_wait_until().
Deprecate the old API based on wallclock time in a GTimeVal.
Fix up the gtk-doc for GCond while we're at it: update the examples to
use static-allocated GCond and GMutex and clarify some things a bit.
Also explain the rationale behind using an absolute time instead of a
relative time.
Make the POSIX backend a little bit more like the win32 one in terms of
how we deal with joinability.
Calling g_system_thread_join() is now optional, and
g_system_thread_wait() can be safely called by multiple threads.
There is no longer any internal concept of joinability.
Wrap GRealThread in a GThreadPosix that includes its own pthread_t field
called "system_thread" and use that instead of the generic field in
GRealThread.
