data-race

Can multiple threads write the same value to the same variable at the same time safely?

时光总嘲笑我的痴心妄想 提交于 2020-01-14 02:55:16
问题 Can multiple threads write the same value to the same variable at the same time safely? For a specific example — is the below code guaranteed by the C++ standard to compile, run without undefined behavior and print "true", on every conforming system? #include <cstdio> #include <thread> int main() { bool x = false; std::thread one{[&]{ x = true; }}; std::thread two{[&]{ x = true; }}; one.join(); two.join(); std::printf(x ? "true" : "false"); } This is a theoretical question; I want to know

Why does this code cause data race?

左心房为你撑大大i 提交于 2020-01-11 10:20:11
问题 1 package main 2 3 import "time" 4 5 func main() { 6 m1 := make(map[string]int) 7 m1["hello"] = 1 8 m1["world"] = 2 9 go func() { 10 for i := 0; i < 100000000; i++ { 11 _ = m1["hello"] 12 } 13 }() 14 time.Sleep(100 * time.Millisecond) 15 m2 := make(map[string]int) 16 m2["hello"] = 3 17 m1 = m2 18 } I run command go run --race with this code and get: ================== WARNING: DATA RACE Read at 0x00c420080000 by goroutine 5: runtime.mapaccess1_faststr() /usr/local/go/src/runtime/hashmap_fast

What formally guarantees that non-atomic variables can't see out-of-thin-air values and create a data race like atomic relaxed theoretically can?

▼魔方 西西 提交于 2019-12-29 01:17:33
问题 This is a question about the formal guarantees of the C++ standard. The standard points out that the rules for std::memory_order_relaxed atomic variables allow "out of thin air" / "out of the blue" values to appear. But for non-atomic variables, can this example have UB? Is r1 == r2 == 42 possible in the C++ abstract machine? Neither variable == 42 initially so you'd expect neither if body should execute, meaning no writes to the shared variables. // Global state int x = 0, y = 0; // Thread 1

Multithreading program stuck in optimized mode but runs normally in -O0

╄→гoц情女王★ 提交于 2019-12-17 22:08:35
问题 I wrote a simple multithreading programs as follows: static bool finished = false; int func() { size_t i = 0; while (!finished) ++i; return i; } int main() { auto result=std::async(std::launch::async, func); std::this_thread::sleep_for(std::chrono::seconds(1)); finished=true; std::cout<<"result ="<<result.get(); std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl; } It behaves normally in debug mode in Visual studio or -O0 in gc c and print out the result after 1 seconds.

What guarantees that different unrelated objects in two unrelated threads don't have an (unavoidable) race condition?

风格不统一 提交于 2019-12-13 10:30:32
问题 When different threads only use unrelated objects and literally do not share anything they cannot have a race condition, right? Obviously. Actually all threads share something: the address space. There is no guarantee that a memory location that was used by one thread isn't going to be allocated at some other time to another thread. This can be true of memory for dynamically allocated objects or even for automatic objects: there is no prescription that the memory space for the "stacks" (the

Why does this code cause data race?

試著忘記壹切 提交于 2019-12-01 22:55:22
1 package main 2 3 import "time" 4 5 func main() { 6 m1 := make(map[string]int) 7 m1["hello"] = 1 8 m1["world"] = 2 9 go func() { 10 for i := 0; i < 100000000; i++ { 11 _ = m1["hello"] 12 } 13 }() 14 time.Sleep(100 * time.Millisecond) 15 m2 := make(map[string]int) 16 m2["hello"] = 3 17 m1 = m2 18 } I run command go run --race with this code and get: ================== WARNING: DATA RACE Read at 0x00c420080000 by goroutine 5: runtime.mapaccess1_faststr() /usr/local/go/src/runtime/hashmap_fast.go:208 +0x0 main.main.func1() /Users/meitu/test/go/map.go:11 +0x80 Previous write at 0x00c420080000 by

Is this compiler transformation allowed?

为君一笑 提交于 2019-11-30 19:02:38
Consider this code, where x and y are integers: if (x) y = 42; Is the following compiler transformation allowed ? int tmp = y; y = 42; if (!x) y = tmp; context : This is from Bjarne Stroustrup's FAQ: // start with x==0 and y==0 if (x) y = 1; // Thread 1 if (y) x = 1; // Thread 2 The FAQ states this is data race free; with x and y both 0, none of the vars should be written to. But what if the transformation is allowed ? Unlike I wrote in my incorrect comment, this transformation is actually not allowed if y is potentially shared between threads and the compiler cannot prove any existing UB in

Is this compiler transformation allowed?

丶灬走出姿态 提交于 2019-11-30 03:17:58
问题 Consider this code, where x and y are integers: if (x) y = 42; Is the following compiler transformation allowed ? int tmp = y; y = 42; if (!x) y = tmp; context : This is from Bjarne Stroustrup's FAQ: // start with x==0 and y==0 if (x) y = 1; // Thread 1 if (y) x = 1; // Thread 2 The FAQ states this is data race free; with x and y both 0, none of the vars should be written to. But what if the transformation is allowed ? 回答1: Unlike I wrote in my incorrect comment, this transformation is

Are “data races” and “race condition” actually the same thing in context of concurrent programming

 ̄綄美尐妖づ 提交于 2019-11-27 10:10:15
I often find these terms being used in context of concurrent programming . Are they the same thing or different ? Baris Kasikci No, they are not the same thing. They are not a subset of one another. They are also neither the necessary, nor the sufficient condition for one another. The definition of a data race is pretty clear, and therefore, its discovery can be automated. A data race occurs when 2 instructions from different threads access the same memory location, at least one of these accesses is a write and there is no synchronization that is mandating any particular order among these

Are “data races” and “race condition” actually the same thing in context of concurrent programming

核能气质少年 提交于 2019-11-26 15:02:40
问题 I often find these terms being used in context of concurrent programming . Are they the same thing or different ? 回答1: No, they are not the same thing. They are not a subset of one another. They are also neither the necessary, nor the sufficient condition for one another. The definition of a data race is pretty clear, and therefore, its discovery can be automated. A data race occurs when 2 instructions from different threads access the same memory location, at least one of these accesses is a