Is memory corruption a possibility with go?

[David Pennington]

I often have objects I want to read/write from multiple places at the same time. In certain places I can use mutexs, however most of the time I'm not actually worried about race-conditions overwriting values - just that some memory corruption might take place and kill the problem.

If two goroutines both want to set a value to true and false at the same time others are reading that value - it's not a problem. Even with locks, almost that same sequence of events will still transpire - just in an organized way.

So my question is, if multiple goroutines are writing/reading the same variable all at the same time, will some of the readers possibly get back a half-written variable value or that two writers might actually corrupt the memory and crash the program?

Is this possible? or are all `foo := bar[foo]` commands always going to get back a FULL value - not a half-written one?

[Ian Lance Taylor]

Just don't do it. It's not worth it. Use locks or channels.

(To answer your specific question, yes, if you are very unlucky, you
can get memory corruption from race conditions, because some Go
values, such as interfaces and slices, span multiple words.)

Ian

[David Pennington]

Finally found it: http://golang.org/doc/faq#atomic_maps

Also, I'm looking at changing my communication from mutexes to create singleton access structs/objects that can listen for requests on channels and block the channel until they make the change to the global objects store. Mutexes will probably be faster.

[Ibrahim M. Ghazal]

Quoting from this blog post (which incidentally was posted just
today): http://dave.cheney.net/2014/06/27/ice-cream-makers-and-data-races

"There is no such thing as a safe data race. Your program either has
no data races, or its operation is undefined."

The worst part about memory corruption is not that your program might
crash. The problem is when the program *doesn't* crash and you get
nonsensical results.

[J. David Lee]

Hi,

This is an implementation detail. You'd probably have to look into the assembly code generated and know something about the architecture to draw a definite conclusion. If two goroutines have a pointer to a boolean that they are reading and setting then it would almost certainly not result in corruption.

David

[Gary Scarr]

Be careful you don't fall into the false assumption that because it's boolean you won't create problems.  In the real sense of "memory corruption" you may be right but you can still get meaningless results as this recent thread revealed to me: https://groups.google.com/d/msg/golang-nuts/dy4aImQAPvk/jMjRq4coLQEJ .  Even though a boolean is most liikely written atomically, if you don't use a mutex there's no guarantee that the compiler will write the register to memory when you expect it, so you can end up with a race.

My takeaway is to always use channels unless profiling shows it to really make a performance difference.  Once you grok the powerful synchronization aspects of channels, just use them.

Gary

[David Pennington]

Since everyonesays even unsafe races are bad, I would rather not get into the habit so I don't need to change my thinking when race conditions are a problem. However, it's hard to find good examples of multi-channel apps to understand in go. I've had to look everywhere to come up with just a small handful of examples. I would really like to see the I/O videos, golang-book, examples, tour, guide, and blog posts talk about more than just simple fan-in functions and such.

Nested up/down stream demos with their own multi-goroutine management would be a big help.

For example, a net.Conn system that has separate processes running which each have their own down-stream services available. Even a simple multi-room chat (each chat room handles it's own clients) would be good.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/c_QuiIgMSGE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.