Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Both threads are only reading the array. For it to be a race, at least one of the accesses must be a write.


The second usage is a mut borrow and I think would be incompatible with a read only borrow if they were run in parallel.

As the comment eludes to, each spawned thread is implicitly joined if you drop the join handle returned by s::spawn().

So in this case the spawned threads run serially.


Nope, the threads run in parallel. The variable x is mutably borrowed only once by the second thread. The variable a is immutably borrowed twice, so there is no issue.


Are you certain?

From the docs on https://doc.rust-lang.org/stable/std/thread/struct.Scope.htm...,

> If the join handle is dropped, the spawned thread will implicitly joined at the end of the scope.

Plus the comment says

> // We can even mutably borrow `x` here, // because no other threads are using it.

Which doesn’t line up with another thread having a read-only borrow on it.

Anyway not at my machine to test right now, I could be wrong.


x is not used by the other thread, a is.

> If the join handle is dropped, the spawned thread will implicitly joined at the end of the scope.

"end of scope" here refers to the end of the closure, after the second thread is spawned.

You can trivially show that the threads exist in parallel by adding waits.


Oh never mind, I’m completely misreading. Thanks for the pointer.


The second use is a mutable borrow of x, not the array. x is borrowed read-only later, after the scoped threads are joined.


ah, that makes sense thanks




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: