After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 667191 - gatomic improvements
gatomic improvements
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-01-03 15:53 UTC by Allison Karlitskaya (desrt)
Modified: 2018-05-24 13:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gatomic: add plain exchange operations (7.57 KB, patch)
2012-01-03 16:48 UTC, Allison Karlitskaya (desrt)
none Details | Review
g_object_clear: use g_atomic_pointer_exchange (2.52 KB, patch)
2012-01-03 16:48 UTC, Allison Karlitskaya (desrt)
none Details | Review
gatomic: add plain exchange operations (9.27 KB, patch)
2012-01-03 16:57 UTC, Allison Karlitskaya (desrt)
none Details | Review

Description Allison Karlitskaya (desrt) 2012-01-03 15:53:14 UTC
gatomic could be improved by the addition of a couple of operations.  We are specifically missing the following:

 - bit set/reset and test-and-set/reset
 - unconditional swap

We don't have support for either of these through GCC intrinsics except in the swap case where we see the following documentation:

type __sync_lock_test_and_set (type *ptr, type value, ...)

    This builtin, as described by Intel, is not a traditional test-and-set
    operation, but rather an atomic exchange operation. It writes value into
    *ptr, and returns the previous contents of *ptr.

    Many targets have only minimal support for such locks, and do not support
    a full exchange operation. In this case, a target may support reduced
    functionality here by which the only valid value to store is the
    immediate constant 1. The exact value actually stored in *ptr is
    implementation defined. 


We could possibly whitelist that one on architectures where we know it to function properly and where we're not concerned about the difference between acquire and full barrier semantics.  I believe this to be true on x86 because the only way this could be implemented is with a xchg instruction which always has an implicit lock prefix, which gives a full barrier.
Comment 1 Allison Karlitskaya (desrt) 2012-01-03 16:28:53 UTC
looks like GCC is finally growing a proper atomic intrinsics API:

http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins


this is going to help a whole lot...
Comment 2 Allison Karlitskaya (desrt) 2012-01-03 16:48:09 UTC
Created attachment 204507 [details] [review]
gatomic: add plain exchange operations

Add a plain exchange operation, natively supported on x86 (where we know
it to work) and emulated with an get/compare/exchange loop elsewhere.
Comment 3 Allison Karlitskaya (desrt) 2012-01-03 16:48:11 UTC
Created attachment 204508 [details] [review]
g_object_clear: use g_atomic_pointer_exchange

We have a plain exchange operation now, so use it.
Comment 4 Allison Karlitskaya (desrt) 2012-01-03 16:57:27 UTC
Created attachment 204510 [details] [review]
gatomic: add plain exchange operations

Add a plain exchange operation, natively supported on x86 (where we know
it to work) and emulated with an get/compare/exchange loop elsewhere.



I forgot to implement the emulated and Windows versions...
Comment 5 Allison Karlitskaya (desrt) 2012-01-03 17:26:03 UTC
implementing the bit operations on intel without compiler support is going to be suboptimal due to the fact that I don't think it's possible for inline assembly to specify that the return result is in a flag...
Comment 6 Allison Karlitskaya (desrt) 2012-01-03 19:40:32 UTC
i figured out a way to work around the problem with returning the result in a flag, but this triggered a GCC bug.

bug is upstream at https://bugzilla.redhat.com/show_bug.cgi?id=771446 and unfortunately that sort of blocks us here, for the time being...
Comment 7 Alexander Larsson 2012-05-02 12:43:31 UTC
The bug seems to be fixed upstream now (from the bz link).
Comment 8 GNOME Infrastructure Team 2018-05-24 13:39:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/495.