-3

I am working on go code and am wondering if it acceptable for there ever to be a race condition. For example, Is it OK to write to a variable in a goroutine that may be used by the main thread as long as the main thread will read the value later anyway? Should race conditions always be avoided, or are there situations in which they are acceptable?

NikolaPi
  • 169
  • 1
  • 9
  • 2
    Race conditions are undefined behavior. It may work "most" of the time, but if you have data race, you lose all guarantees. I don't want to run an app that doesn't guarantee anything. – icza Aug 23 '20 at 21:25
  • If you want well-defined reproducible behavior, avoid races. If you want to have nondeterministic and nonreproducible behavior, a race would give you what you need. – Burak Serdar Aug 23 '20 at 21:32
  • 1
    https://software.intel.com/content/www/us/en/develop/blogs/benign-data-races-what-could-possibly-go-wrong.html – JimB Aug 23 '20 at 22:37

1 Answers1

1

TL;DR
Race conditions are harmful and may be the cause of vulnerabilities.

What are race conditions?
Race condition means that multiple threads want the same resource and that the order of the thread that gets that resource is dependent on the actual run, therefore non-deterministic.


Is it always dangerous?
It's like a horse race, where different threads are the different horses: if your software requires specific horse (thread) to get first (the resource) for its valid execution it's a problem - yet if you are careless regarding the order of the threads getting the resource it's fine.


Security Perspective
Race conditions are usually harmful and even cause vulnerabilities, such as dirtyc0w.

Aviv Yaniv
  • 6,188
  • 3
  • 7
  • 22