On Mon, Jun 30, 2014 at 08:17:18AM -0700, Jarno Rajahalme wrote:
> Updating the reference count only requires atomicity, but no memory
> ordering with respect to any other loads or stores.  Avoiding the
> overhead of the default memory_order_seq_cst can make these more
> efficient.
> 
> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com>

This website makes pretty different claims:
        
http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/atomic/usage_examples.html

Relevant excerpts:

    #include <boost/intrusive_ptr.hpp>
    #include <boost/atomic.hpp>

    class X {
    public:
      typedef boost::intrusive_ptr<X> pointer;
      X() : refcount_(0) {}

    private:
      mutable boost::atomic<int> refcount_;
      friend void intrusive_ptr_add_ref(const X * x)
      {
        x->refcount_.fetch_add(1, boost::memory_order_relaxed);
      }
      friend void intrusive_ptr_release(const X * x)
      {
        if (x->refcount_.fetch_sub(1, boost::memory_order_release) == 1) {
          boost::atomic_thread_fence(boost::memory_order_acquire);
          delete x;
        }
      }
    };

...

    Increasing the reference counter can always be done with
    memory_order_relaxed: New references to an object can only be formed
    from an existing reference, and passing an existing reference from one
    thread to another must already provide any required synchronization.

    It is important to enforce any possible access to the object in one
    thread (through an existing reference) to happen before deleting the
    object in a different thread. This is achieved by a "release"
    operation after dropping a reference (any access to the object through
    this reference must obviously happened before), and an "acquire"
    operation before deleting the object.

    It would be possible to use memory_order_acq_rel for the fetch_sub
    operation, but this results in unneeded "acquire" operations when the
    reference counter does not yet reach zero and may impose a performance
    penalty.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to