# Ice Cream Makers and Data Races Part II

DevFeed: [Ice Cream Makers and Data Races Part II](<https://devfeed.tech/articles/ice-cream-makers-and-data-races-part-ii-22102.md>)

Original publisher: [Read original article](<https://www.ardanlabs.com/blog/2014/06/ice-cream-makers-and-data-races-part-ii.html>)

Published: 2014-06-27T00:00:00Z

Content type: tutorial

Language: en

Sources: [William Kennedy](<https://devfeed.tech/sources/william-kennedy.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [race-condition](<https://devfeed.tech/topics/race-condition.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [ardan-labs](<https://devfeed.tech/tags/ardan-labs.md>), [blog](<https://devfeed.tech/tags/blog.md>), [code](<https://devfeed.tech/tags/code.md>), [go](<https://devfeed.tech/tags/go.md>), [go-programming](<https://devfeed.tech/tags/go-programming.md>), [golang](<https://devfeed.tech/tags/golang.md>), [goroutines](<https://devfeed.tech/tags/goroutines.md>), [interface](<https://devfeed.tech/tags/interface.md>), [memory](<https://devfeed.tech/tags/memory.md>), [programming](<https://devfeed.tech/tags/programming.md>), [race-condition](<https://devfeed.tech/tags/race-condition.md>)

## AI overview

This article examines a data race in Go caused by unsynchronized reads and writes to an interface-typed variable. It explains how partial writes can cause method implementations for different receiver types to operate on incompatible memory representations.

## Source excerpt

Introduction Dave Cheney published a post called Ice Cream Makers and Data Races. The post showed an example of an interesting data race that can occur when using an interface typed variable to make a method call. If you have not read the post yet please do. Once you read the post you will discover that the problem lies with the fact that an interface value is implemented internally using a two word header and that the Go memory model states only writes to a single word are atomic. The program in the post shows a race condition that allows two goroutines to perform a read and write operation at the same time against an interface value. Not synchronizing this read and write allows the read to observe a partial write to the interface value. This allows the method implementation for the Ben type to operate against a value of the Jerry type and visa versa. In Dave's example, the layout of the Ben and Jerry structs were identical in memory, so they were in some sense compatible. Dave suggested the chaos that would occur if they had different memory representations. This is because each implementation of the Hello method assumes the code is operating against values of the receiver type. When this bug surfaces, this is no longer the case. To give you a visual view of this suggested chaos, I am going to change the declaration of the Jerry type in two different ways. Both changes will give you some better insight into the interworking of interface types and memory. First Code Change Let's review the code and see the first set of changes. My changes to the original code are in bold: