Consider moving from parking_lot back to std locks

[bjorn3]

What problem does this solve or what need does it fill?

In the past the locks in libstd were wrappers around the OS native locks like provided by pthreads. Depending on the use case the locks of parking_lot are faster. For this reason we currently use parking_lot instead. As part of the work tracked in rust-lang/rust#93740 libstd is currently replacing OS native locks with custom implementations. The linux implementation is slightly slower than parking_lot when there is no contention, but it is faster than both parking_lot and the pthreads implementation of glibc and musl under light to extreme contention on at least two benchmarks (Amanieu/parking_lot#338 (comment) and rust-lang/rust#95035 (comment)).

What solution would you like?

We should benchmark the new locking implementation of libstd for the purposes of bevy and switch to them if they don't regress performance. Even if they don't improve

What alternative(s) have you considered?

Wait until rust-lang/rust#93740 is fully done.

[ManevilleF]

I think this can be unblocked with the 1.62.0 release

[Elabajaba]

A reason why we might want to stick with parking_lot is its deadlock detection.

Another option might be using the debug variants of tracing-mutex, which creates a DAG and ensures that there aren't any lock cycles (and the debug variants only do that for debug builds, but otherwise use the underlying std/parking_lot/etc primitives).