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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
