Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can I concurrently write different slice elements

I have a slice that contains work to be done, and a slice that will contain the results when everything is done. The following is a sketch of my general process:

var results = make([]Result, len(jobs)) wg := sync.WaitGroup{} for i, job := range jobs {     wg.Add(1)     go func(i int, j job) {         defer wg.Done()         var r Result = doWork(j)         results[i] = r     }(i, job) } wg.Wait() // Use results 

It seems to work, but I have not tested it thoroughly and am not sure if it is safe to do. Generally I would not feel good letting multiple goroutines write to anything, but in this case, each goroutine is limited to its own index in the slice, which is pre-allocated.

I suppose the alternative is collecting results via a channel, but since order of results matters, this seemed rather simple. Is it safe to write into slice elements this way?

like image 559
captncraig Avatar asked Apr 17 '18 13:04

captncraig


People also ask

Are slices concurrent safe?

In Go no value is safe for concurrent read/write, slices (which are slice headers) are no exception.

What is a slice data type?

slice is a composite data type and because it is composed of primitive data type (see variables lesson for primitive data types). Syntax to define a slice is pretty similar to that of an array but without specifying the elements count. Hence s is a slice.


2 Answers

The rule is simple: if multiple goroutines access a variable concurrently, and at least one of the accesses is a write, then synchronization is required.

Your example does not violate this rule. You don't write the slice value (the slice header), you only read it (implicitly, when you index it).

You don't read the slice elements, you only modify the slice elements. And each goroutine only modifies a single, different, designated slice element. And since each slice element has its own address (own memory space), they are like distinct variables. This is covered in Spec: Variables:

Structured variables of array, slice, and struct types have elements and fields that may be addressed individually. Each such element acts like a variable.

What must be kept in mind is that you can't read the results from the results slice without synchronization. And the waitgroup you used in your example is a sufficient synchronization. You are allowed to read the slice once wg.Wait() returns, because that can only happen after all worker goroutines called wg.Done(), and none of the worker goroutines modify the elements after they called wg.Done().

For example, this is a valid (safe) way to check / process the results:

wg.Wait() // Safe to read results after the above synchronization point: fmt.Println(results) 

But if you would try to access the elements of results before wg.Wait(), that's a data race:

// This is data race! Goroutines might still run and modify elements of results! fmt.Println(results) wg.Wait() 
like image 120
icza Avatar answered Sep 28 '22 00:09

icza


Yes, it's perfectly legal: a slice has an array as its underlying data storage, and, being a compound type, an array is a sequence of "elements" which behave as individual variables with distinct memory locations; modifying them concurrently is fine.

Just be sure to synchronize the shutdown of your worker goroutines with the main one before it reads the updated contents of the slice.

Using sync.WaitGroup for this—as you do—is perfectly fine.

Also, as @icza said, you must not modify the slice value itself (which is a struct containing a pointer to the backing storage array, the capacity and the length).

like image 26
kostix Avatar answered Sep 28 '22 01:09

kostix