Potential to modify the ordering for 'load' operations in the garbage module of branch 0.2.10 about crossbeam HOT 4 CLOSED

Relaxed at 133 is fine because head loaded from 133 is not dereferenced. The actual value to be dereferenced is acquired-swapped at 135.

Also actually the load at 124 can be relaxed (thanks to release sequence). And .next field can be non-atomic.

should use Acquire to observe other modifications made to this memory address

release-acquire synchronization is about conditionally passing the knowledge about other locations, not the location that is being stored to and loaded from.

from crossbeam.

May I submit a pull request?

I'm not interested in accepting an optimization patch for a 7 year old release, but I would be willing to accept a patch to the latest version.

from crossbeam.

release-acquire synchronization is about conditionally passing the knowledge about other locations, not the location that is being stored to and loaded from.

I agree. My initial thought is that the location stored by AtomicPtr is a pointer, yet the content it points to is non-atomic. Indeed, line 137 does not perform dereferencing; I was mistaken. It appears I need to revise the detection pattern.

from crossbeam.

Hm, I've updated the detection pattern, successfully eliminating the false positive.

  {
    "AtomicCorrelationViolation": {
      "bug_kind": "AtimicCorrelationViolation",
      "possibility": "Possibly",
      "diagnosis": {
        "atomic": "/Users/wangcheng/.cargo/registry/src/index.crates.io-6f17d22bba15001f/crossbeam-0.2.12/src/mem/epoch/garbage.rs:124:34: 124:47"
      },
      "explanation": "Using an atomic operation with a stronger memory ordering than necessary can lead to unnecessary performance overhead. Using Relaxed is sufficient to ensure the correctness of the program"
    }
  },

from crossbeam.