this post was submitted on 05 Oct 2024
104 points (94.8% liked)

Programming

17484 readers
86 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] nous@programming.dev 4 points 1 month ago (1 children)

How are they not memory safe in a multi-threadded context?

[–] unique_hemp@discuss.tchncs.de 4 points 1 month ago (1 children)

There's nothing to prevent data races. I myself have fallen into the trap of using the same list from multiple threads.

[–] nous@programming.dev 10 points 1 month ago (2 children)

I don't think data races are generally considered a memory safety issue. And a lot of languages do not do much to prevent them but are still widely considered memory safe.

[–] calcopiritus@lemmy.world 4 points 1 month ago

Even though they are not what people mean when they say "memory-safe", it is technically a kind of memory safety. It is unsafe to modify non-mutexed/non-atomic memory that another thread might be modifying at the same time.

[–] Ephera@lemmy.ml 2 points 1 month ago (1 children)

Yeah, that is why I prefixed that whole comment with "arguably".

I feel like the definition of memory safety is currently evolving, because I do think data races should be considered a memory safety issue.
You've got a portion of memory and access to it can be done wrongly, if the programmer isn't careful. That's what memory safety is supposed to prevent.

Rust prevents that by blocking you from passing a pointer for the same section of memory into different threads, unless you use a mutex or similar.
And because Rust sets a new safety standard, I feel like we'll not refer to Java and such as "memory-safe" in twenty years, much like you wouldn't call a car from the 90s particularly safe, even though it was at the time.

[–] Saizaku@lemmy.dbzer0.com 5 points 1 month ago (2 children)

There's a reason why data races aren't considered a memory safety issue, because we have a concept that deals with concurrency issues - thread safety.

Also for all it's faults, thread and memory safety in java aren't issues. In fact java's concurrent data structures are unmatched in any other programming language. You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it's a bit of a moot point.

[–] Ephera@lemmy.ml 4 points 1 month ago

Oof, I guess, you're not wrong that we've defined data races to be the separate issue of thread safety, but I am really not a fan of that separation.

IMHO you cannot cleanly solve thread safety without also extending that solution to the memory safety side.
Having only one accessor for a portion of memory should just be the n=1 case of having n accessors. It should not be the other way around, i.e. that multiple accessors are the special case. That just leads you to building two different solutions, and to thread safety being opt-in.

That's also the major issue I have with Java's solution.
If you know what you're doing, then it's no problem. But if you've got a junior hacking away, or you're not paying enough attention, or you just don't realize that a function call will take your parameter across thread boundaries, then you're fucked.
Well, unless you make everything immutable and always clone it, which is what we generally end up doing.

[–] arendjr@programming.dev 2 points 1 month ago

You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it’s a bit of a moot point.

In Java it isn’t always clear when something crosses a thread boundary and when it doesn’t. In Rust, it is very explicit when you’re opting into using unsafe, so I think that’s a very clear distinction.

Java provides classes for thread safe programming, but the language isn’t thread safe. Just like C++ provides containers for improved memory safety, and yet the language isn’t memory safe.

The distinction lies between what’s available in the standard library, and what the language enforces.