Are primitive variable values like int, bool etc. atomic in GDScript?

[just-like-that]

I've read the chapter about threading in Godot.

Multiple Threads

At the end of the chapter is an example given about Semaphores.
Semaphores

In method _exit_tree() a boolean variable named exit_thread is encapsulated by a mutex.

func _exit_tree():
    mutex.lock()
    exit_thread = true # Protect with Mutex.
    mutex.unlock()

    # shortened for reasons of clarity

It implies that boolean variables are NOT atomic on read or write access.

I was assuming primitive values are always atomic even in a multi-threaded context.

A boolean is either true or false.

So what's the truth behind it?

[theraot]

As far as I know they are not guaranteed to be atomic.

Also, that would be a Variant that happens to have a bool value.

I'd like to atomic integers in Godot… But, I had not run into a situation where having them was critical.

[just-like-that]

GDScript arrays, dictionaries
teaches us:

In GDScript, reading and writing elements from multiple threads is OK, but anything that changes the container size (resizing, adding or removing elements) requires locking a mutex.

So if a read or write in an array or dictionary is thread-safe then a simple read or write on primitive values should do too.

Right?!

[theraot]

Writing the Array (https://github.com/godotengine/godot/blob/3.x/core/array.cpp#L74) uses write from the member array of the member _p of Array.

The member _p of Array is declared as PrivateArray (https://github.com/godotengine/godot/blob/3.x/core/array.h#L42).

The array member of PrivateArray is a Vector<Variant> (https://github.com/godotengine/godot/blob/3.x/core/array.cpp#L41).

Vector<Variant>.write is a VectorWriteProxy<Variant>? (https://github.com/godotengine/godot/blob/3.x/core/vector.h#L60), oh it is a function that just writes (https://github.com/godotengine/godot/blob/3.x/core/vector.h#L51) (with a bound check and marked to be inlined).

And Variant - by the way - is like a discriminated union (https://github.com/godotengine/godot/blob/3.x/core/variant.h#L135-L166).

Perhaps they mean by "thread-safe" that it won't crash? Anyway, I don't see how that would be an atomic write. I might be missing something, as there are things I don't understand, but I as far as I can tell Variant would be too large to be automatically atomic, and Vector<Variant> does not seem to do something to help it either.

[theraot]

Beyond if the read and write of an int is atomic. I would want atomic increments and decrements, exchange and compare exchange. Otherwise even with atomic read and write we still have the ABA problem.

[just-like-that]

Agreed. That was my next step to find out if int-variable += 1 is atomic too. The documentation is too little precise on this.

On Aug 4, 2022, 04:00, at 04:00, "Alfonso J. Ramos" ***@***.***> wrote: Beyond if the read and write of an int is atomic. I would want atomic increments and decrements, exchange and compare exchange. Otherwise even with atomic read and write we still have the [ABA problem](https://en.wikipedia.org/wiki/ABA_problem). -- Reply to this email directly or view it on GitHub: #4983 (reply in thread) You are receiving this because you authored the thread. Message ID:

***@***.***>

[just-like-that]

Thank you for your analysis. The reason why I am asking this, to avoid synchronization when it's unnecessary on a language level. 👍

On Aug 2, 2022, 17:36, at 17:36, "Alfonso J. Ramos" ***@***.***> wrote: Writing the `Array` (https://github.com/godotengine/godot/blob/3.x/core/array.cpp#L74) uses `write` from the member `array` of the member `_p` of `Array`. The member `_p` of `Array` is declared as `PrivateArray` (https://github.com/godotengine/godot/blob/3.x/core/array.h#L42). The `array` member of `PrivateArray` is a `Vector<Variant>` (https://github.com/godotengine/godot/blob/3.x/core/array.cpp#L41). `Vector<Variant>.write` is a `VectorWriteProxy<Variant>`? (https://github.com/godotengine/godot/blob/3.x/core/vector.h#L60), oh it is a function that just writes (https://github.com/godotengine/godot/blob/3.x/core/vector.h#L51) (with a bound check and marked to be inlined). And `Variant` - by the way - is like a discriminated union (https://github.com/godotengine/godot/blob/3.x/core/variant.h#L135-L166). Perhaps they mean by "thread-safe" that it won't crash? Anyway, I don't see how that would be an atomic write. *I might be missing something, as there are things I don't understand, but I as far as I can tell `Variant` would be too large to be automatically atomic, and `Vector<Variant>` does not seem to do something to help it either.* -- Reply to this email directly or view it on GitHub: #4983 (reply in thread) You are receiving this because you authored the thread. Message ID:

***@***.***>

[just-like-that]

I found following post:
Using Dictionaries in Thread
From my understanding w/o the mutex there is COW on action.
Imo that means different threads are working on different copies of a dictionary.
Needs further investigation. :)

[theraot]

As far as I understand, It is a simple race condition: to increase the size it has to allocate a new buffer, copy the data to the new buffer, and update the reference so the Dictionary points to the new buffer. Not every write might do that, only those that would add elements may require to increase the size.

If there is another thread accessing the Dictionary at the same time it might enter before the reference to the buffer changed to the new one, so it will use the old buffer. One of these happens:

• If the other thread manages to write (and it is visible to other threads) before the first threads copies the data, then it happens to work.
• The data the other thread is writing could be copied wrong since that write is not atomic.
• Otherwise, the change will be lost, because the Dictionary now points to the new buffer where the data was not copied.

[just-like-that]

To sum it up:

If there are lots of readers and one writer only then we do not need synchronization.
The readers read data which might be up-to-date or NOT depending on if there is currently an update going on.

If there are more than one writer, synchronization of shared resources is necessary to always have the most up-to-date version
(in case I'm dependent on the former state like with counters etc... ).

I think what the chapter about thread-safety in the context of collections means is that a reader gets accurate data - it might just be out-dated due to COW which is the mechanism to ensure that all data is accurate at all.

[theraot]

If there are lots of readers and one writer only then we do not need synchronization.

If a write is not atomic, a reader which access a value that is being written could see a corrupted value. To be more precise, it could see a value that is partially written. That happens because the write does not happens all at once, but by chunks, which happens because the value is too big to write all at once. And as far as I can tell, that is the case with Variant.

Also please notice this might be platform specific.

[theraot]

I've been pointing out how threaded access can go wrong. For a change, let me tell you a pattern that will work:

• Have a variable with the number of threads you are going to use.
• Make an array, and make sure its size matches the number of threads you are going to use.
• Give each thread an index form 0 to the number of threads minus 1.
• Each thread will only access the array on the index given to them.
• When the threads are done, you are going to use call_deferred to notify they are done.
• You can either:
  • Have the thread report their index, which lets you know which value of the array is ready to be aggregated. This will also allow you to reuse (Godot threads are very easy to reuse) or spawn a new thread with the same index after you have used the value.
  • Or you can count the number of threads that finished, and when they are all done, you aggregate all the data in the array.

Notice that at you only size the array at the start, you never resize it. And also notice that at no point will two threads try to access the same value on the array.

[just-like-that]

Hi,
thank you for bringing this up.

Separation of responsibility is a good thing.

Multi-threading might perform the most without the synchronization being the bottleneck.

Good talk!