Rust

5999 readers

7 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

[email protected]

[BLOG] Why Rust mutexes look like they do - Cliffle (cliffle.com)

submitted 2 months ago by [email protected] to c/[email protected]

18 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 18 points 2 months ago (2 children)

It's a massive win, and I would question the credibility of any systems programmer that doesn't recognize that as soon as they understand the wrapper arrangement. I would have to assume that such people are going around making egregious errors in how they're using mutexes in their C-like code, and are the reason Rust is such an important language to roll out everywhere.

The only time I've ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.

[–] [email protected] 6 points 2 months ago (1 children)

Exactly. If there's only one thing I could bring from Rust into another language, it would be Mutexes. It's so nice to guarantee safe access to data.

[–] [email protected] 6 points 2 months ago* (last edited 2 months ago) (1 children)

Rust mutexes would be nice. But I think for me that one thing for me would be its enums.

[–] [email protected] 5 points 2 months ago

But only if pattern matching were included, otherwise they would be as unpleasant as C++'s std::variant.

[–] [email protected] 5 points 2 months ago (1 children)

The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.

Actually I think in this case you're still better off using a Mutex with "data" inside. I've done this before. The idea is that you make a unit struct MyCFuncs or whatever and then you only call the C functions from methods of that unit struct. Then you can only access those methods once you lock the Mutex and get the instance of the unit struct. It feel elegant to me.

[–] [email protected] 2 points 2 months ago (1 children)

This makes a lot of sense, but the functions were Rust bindings for plain C functions, they weren't function pointers. Granted I could have put pointers to the function bindings into fields in a struct and stored that struct in the mutex, but the ability to anyhow call the bindings would still exist.

[–] [email protected] 1 points 2 months ago

They were also plain C functions in my case, but it doesn't take too much discipline to only call it through the struct. Also, you can put the struct in a different crate which includes the C bindings to ensure that you can't call the C bindings without the struct.