Possibility of underflow

[abh1nav10]

Addresses #976.

Remote::schedule does a fetch_add with Ordering::Release on the counter. Ordering::Release only guarantees that the operations before it will not be reordered to happen after it but does not guarantee that the operations after it will not be reordered to happen before it.
That leads to the possibility of the the same scenario in which the executor might fetch_sub before the counter was incremented which would lead to underflow.

We need the semantics of the Acquire ordering here(ops after it are not reordered to happen before it).

[George-Miao]

@abh1nav10 Yes, only a Acquire-Release won't cut the deal; but there's the an release-acquire pair and a SeqCst imposed by ArrayQueue::pop in between the load-store pair, which makes the reordering you mentioned impossible. And even if there's nothing in between and the recordering may happen, the proposed change you mentioned won't do the trick here either since storing with Acquire is basically Relax (and i think rust won't even let you do this).

[abh1nav10]

ArrayQueue::pop preventing it from happening makes sense. Should have given in more thought before filing the issue :( Thanks for making it clear. @George-Miao
But, if we plug the Acquire ordering into it, the load part of fetch_add as the standard library documents will get the semantics of that ordering but the store as you pointed out would be Relaxed. Won't that load part of fetch_add being Acquire do the job(no reordering of ops before it) assuming nothing like pop was in between? The store part of fetch_add being Relaxed seems fine because there's no memory operations before it that we want to be visible to other threads who Acquire on our fetch_add later. Rust does allow us to put an Acquire ordering on a fetch_add. Out of curiosity :)