OK sorry that was a mistake. It's not a race.

But it's still non-local. one has to manually account for what allocation will be done, and keep the reservation in sync across refactors. This isn't a race but still scares me.

Someone could write

    shared_v.lock().try_reserved();
    shared_v.lock().something();

which would be a race. That is not `try_reserved`'s fault, and a rather easy-to-spot example, but I wonder if there are variations on this which are easier to miss.

They probably meant it is a race, not racy. Although, it's not a race I think? The method will attempt to reserve, or return Err, just like malloc would (it's not can_reserve)

I think they're referring to something like this

    let v = vec![0; 42];
    v.try_reserve(1);
    frob(&mut v); // I expect this not to expand the array
    v.push(1); // fails, because frob took the space

Note that this requires passing a mutable reference to frob. Absent an explicit contract in the api documentation I wouldn't expect a function that takes a mutable reference to a vec not to mutate it arbitrarily.

One option for avoiding this would be to pass a mutable reference to a slice, which allows frob to mutate elements of the vec without allowing it to push.

   frob(&v[..])

It can't be a race in the traditional sense, as the borrow checker will enforce only one person being able to write at a time.

Yes exactly. Thanks.

Causing (or allowing) race conditions