Append Function: Not Thread-Safe for Concurrent Access

When utilizing goroutines concurrently to append elements to a slice within a for loop, anomalies in data can arise. Missing or blank data may appear in the resultant slice, indicating potential data races.

This occurs because in Go, no value is innately safe for simultaneous read and write. Slices, which are represented by slice headers, are no exception. The code provided exhibits data races due to concurrent access:

destSlice := make([]myClass, 0)

var wg sync.WaitGroup
for _, myObject := range sourceSlice {
    wg.Add(1)
    go func(closureMyObject myClass) {
        defer wg.Done()
        var tmpObj myClass
        tmpObj.AttributeName = closureMyObject.AttributeName
        destSlice = append(destSlice, tmpObj)
    }(myObject)
}
wg.Wait()

To verify the presence of data races, execute the following command:

go run -race play.go

The output will alert you to data races:

WARNING: DATA RACE
...

Resolving Concurrency Issues

To resolve this issue, protect the write access to the destSlice by employing a sync.Mutex:

var (
    mu        = &sync.Mutex{}
    destSlice = make([]myClass, 0)
)

var wg sync.WaitGroup
for _, myObject := range sourceSlice {
    wg.Add(1)
    go func(closureMyObject myClass) {
        defer wg.Done()
        var tmpObj myClass
        tmpObj.AttributeName = closureMyObject.AttributeName
        mu.Lock()
        destSlice = append(destSlice, tmpObj)
        mu.Unlock()
    }(myObject)
}
wg.Wait()

Alternatively, consider using a channel to asynchronously handle the appends:

var (
    appendChan = make(chan myClass)
    destSlice  = make([]myClass, 0)
)

var wg sync.WaitGroup
for _, myObject := range sourceSlice {
    wg.Add(1)
    go func(closureMyObject myClass) {
        defer wg.Done()
        var tmpObj myClass
        tmpObj.AttributeName = closureMyObject.AttributeName
        appendChan