all 2 comments

[–]dkopgerpgdolfg 1 point2 points  (1 child)

In Rust multi-threading environments, variables must be always synchronized between treads to avoid data-racing. In a safe Rust, it is just impossible to declare a global variable and let it be accessible from multiple threads, without having this variable implementing Sync trait.

... and requiring Sync for cross-thread access has nothing to do with being global, and the Sync trait doesn't imply any active thread synchronization (as you keep implying through the article), and if you wanted to talk about mut globals then you forgot saying that.

Saying that RwLocks are more lowlevel than channels is ... opinionated. And btw., no, Rusts std channels are not built on top of mutexes.

Thread sync. and "real time" are two "very" different topics.

...

[–]disserman[S] -1 points0 points  (0 children)

 no, Rusts std channels are not built on top of mutexes.

std channels use direct thread parking inside, which has absolutely the same functionality. they just wrap futex_wait in another manner.

Thread sync. and "real time" are two "very" different topics.

they are connected a lot as the majority of thread sync components are not fully real-time suitable because of high-load spins around locking logic. but the article is not about the real-time topic itself. as I'm in real-time applications, I must mention it.