Are Weaker Memory Ordering Constraints Possible?

[alice]

The replacement for get_mut is with_mut.

[Phlopsi]

Good news: I got the test running

Bad news: I tried changing both orderings to relaxed to fail on purpose, but it didn't…

Here's the test:

#[test]
fn arc() {
    ::loom::model(|| {
        let value: [u64; 10] = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
        let raw_arc = ::impatience::Arc::raw(value);

        let thandle0 = ::loom::thread::spawn(move || unsafe {
            ::std::mem::drop(::impatience::Arc::<[u64; 10]>::from_raw(raw_arc))
        });

        let thandle1 = ::loom::thread::spawn(move || unsafe {
            let arc = ::impatience::Arc::<[u64; 10]>::from_raw(raw_arc);
            arc.init_count(2);
            ::std::mem::drop(arc);
        });

        thandle0.join().unwrap();
        thandle1.join().unwrap();
    });
}

(Github)

$ RUSTFLAGS="--cfg loom" cargo test --test loom_arc

It seems I set my expectations for Loom too high. Maybe, someday, it'll be of help, but not today.

EDIT:
It'll be a bit difficult for anyone else to run the test, at the moment. I'll have to make some adjustments in the Cargo.toml.

[Phlopsi]

Update:

1. I opened a pull request to add support for atomic signed integer types to Loom
2. I looked through the C++ working draft from 2012-01-16 (N3337) and I found the following rule stated in § 29.3 (Order and consistency), 12:

Atomic read-modify-write operations shall always read the last value (in the modification order) written before the write associated with the read-modify-write operation.

That means, fetch-add and fetch-sub will always be in sync with every other atomic operation <EDIT: performing on the same atomic object>. Due to the concurrent correctness of my custom Arc only depending on these 2 read-modify-write operations, it is totally fine to use relaxed ordering for both of them. As it turns out, Loom was actually correct.

[riking]

@Phlopsi

That means, fetch-add and fetch-sub will always be in sync with every other atomic operation

...on the same address.

Acquire/Release affect what has been done to other memory addresses, e.g. the struct you're protecting inside your Arc<>. The memory orderings are named for their affect on Mutex<>.