[Gluster-devel] Standardized atomic inc/dec/add/sub operations

[Niels de Vos]

I would like to have your attention to a new set of macros for atomic
operations. It is the intention to make the atomic operations a little
easier to use, and have them be architecture independent. From
https://review.gluster.org/16963:

    The current macros ATOMIC_INCREMENT() and ATOMIC_DECREMENT() expect a
    lock as first argument. There are at least two issues with this
    approach:
    
      1. this lock is unused on architectures that have atomic operations
      2. some structures use a single lock for multiple variables
    
    By defining a gf_atomic_t type, the unused lock can be removed, saving a
    few bytes on modern architectures.
    
    Because the gf_atomic_t type locates the lock for the variable (in case
    of older architectures), each variable is protected the same on all
    architectures. This makes the behaviour across all architectures more
    equal (per variable locking, by a gf_lock_t or compiler optimization).


Usage looks like this:

    gf_atomic_t counter;
    int64_t     i;

    GF_ATOMIC_INIT (counter, 0);     /* initialize and set to 0 */
    i = GF_ATOMIC_INC (counter);     /* increment by 1 */
    i = GF_ATOMIC_DEC (counter);     /* decrement by 1 */
    i = GF_ATOMIC_ADD (counter, 16); /* add 16 */
    i = GF_ATOMIC_SUB (counter, 16); /* subtract 16 */


This should be ready for inclusion soon, definitely before 3.11. It is
not really a feature, but more of a maintenance cleanup. I'm sending
this email to let everyone know that ATOMIC_INCREMENT() and
ATOMIC_DECREMENT() will be removed with this change. Any patches that
are planned for 3.11 with these macros will need to be updated.

Let me know on this list if there are any questions or concerns. Thanks,
Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170330/8f2beef3/attachment.sig>