Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
From discussion, GVariantIter is not useful for bindings, but
GVariantBuilder may be.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
Add a performance test for bitlocks.
Make use of the new g_atomic_int_{and,or} to avoid having to do the
usual compare-and-exchange loop.
On a test machine, the change increases performance from approximately
20 million uncontended acquire/releases per second to 31 million.
Commit 22e7fc34c44c5ef95abf4fed429f2345410cc82c introduced a regression:
futexes were always disabled and the emulated codepath was always being
used. That commit was in response to an originally buggy
implementationt hat wrote junk into config.h (but happened to be working
properly).
Fix up the mess and while we're at it, close bug #631231 by including
syscall.h from the correct location and using __NR_futex instead of
SYS_futex.
Closes#631231.
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
* g_static_private_get: have a single entry and exit
* g_static_private_set: delay creation of GArray so the whole tail of
the function can be under the private_data lock without risking
deadlock with the g_thread lock; call the destructor last, after
we could have unlocked
* g_static_private_free: choose next thread in list before accessing
private_data, to keep all accesses together
* g_thread_cleanup: steal private_data first, then work exclusively with
the stolen array (which doesn't need to be under a lock any more)
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=642026
Bug-NB: NB#257512
Make sure that the macros work properly with the range of types that
they are documented to work with and ensure that no strict aliasing
warnings are issued (even at the highest warning level).
https://bugzilla.gnome.org/show_bug.cgi?id=650935
Ensure callers get a warning if they pass a bad length.
Split into a separate commit and changed to order index before
n_children by Colin Walters <walters@verbum.org>
During the recent refactorings of GHashTable a bug was introduced
where removing all nodes from a hash table would leave tombstones
behind, but make the counts appear like there are none.
Reported and tracked down by Carlos Garnacho,
https://bugzilla.gnome.org/show_bug.cgi?id=651141
This commit also adds a test that checks the internal consistency
of GHashTable over several insert/remove/remove-all operations.
The grouping in files/headers is not used anymore, and
the function attributes neither. Adapt abicheck scripts
and .def file generation rules accordingly.
When using gcc builtins for atomic operations, provide them
as macros, so gcc can see the builtins and do optimizations.
This change gives considerable speedups in bitlocks, which
use atomic operations heavily, see bug 650458.
Also, don't define G_ATOMIC_OP_MEMORY_BARRIER_NEEDED unconditionally
when using gcc builtins.
https://bugzilla.gnome.org/show_bug.cgi?id=617491
