Bug 15256 – Data races with arrays allowed in @safe code
Status
RESOLVED
Resolution
WORKSFORME
Severity
critical
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-10-29T09:10:13Z
Last change time
2022-10-13T08:00:56Z
Keywords
accepts-invalid, safe
Assigned to
No Owner
Creator
anonymous4
Comments
Comment #0 by dfj1esp02 — 2015-10-29T09:10:13Z
@safe:
shared string s;
void f() @safe
{
s="s";
}
A slice is stored with two mov instructions, so when the global variable is modified concurrently, it can end up with pointer from one array and length from another.
Comment #1 by jack — 2017-01-19T14:42:28Z
This is more an issue with shared than with @safe. AFAIK @safe makes no guarantees when it comes to data races.
Comment #2 by dfj1esp02 — 2017-01-20T12:42:18Z
@safe exists to makes guarantees :)
And memory safety and data races are not shared's issues.
Comment #3 by jack — 2017-01-20T12:49:48Z
(In reply to anonymous4 from comment #2)
> @safe exists to makes guarantees :)
> And memory safety and data races are not shared's issues.
Data races are absolutely shared's problem. The issue is shared has never been fully implemented. See https://issues.dlang.org/show_bug.cgi?id=14932
The only place you can see what shared is supposed to be is in Andrei's book "The D Programming Language".
@safe exists to ensure memory safety; data races do not fall under that umbrella.
Comment #4 by dfj1esp02 — 2017-01-20T13:08:08Z
If you corrupt memory in @safe code, then @safe fails, I think, this is specified pretty clearly, whether this happens due to sharing is unimportant. If shared should allow data races can be discussed in issue 14932.
Comment #5 by razvan.nitu1305 — 2022-10-13T08:00:56Z
If you compile with -preview=nosharedaccess than this code no longer compiles: "Error: direct access to shared `s` is not allowed, see `core.atomic`". Closing as WORKSFORME.