Hi! I’ve been working on this “light controller” script that essentially maintains connections and coroutines. And when said connections and coroutines are no longer needed: it disconnects or closes them to free up memory. The connections and coroutines are maintained in a global table and are accessed/modified by multiple threads. The question I have or at least wonder about is whether or not access to the said global table is safe (i.e., no race conditions will occur). And if so, then are there any methods to synchronize such access? Many thanks! : )
1 Like
The question I have or at least wonder about is whether or not access to the said global table is safe (i.e., no race conditions will occur). And if so, then are there any methods to synchronize such access?
Depends on how the clients behave with regards to the controller.
Recall race conditions only occur when two separate clients with access to the same data try to change the data (in the critical section, at least) at the same time, which is going to be entirely dependent on a) how many clients you have using the controller and b) how much data they are sharing (the data in a global table isn’t necessarily all going to be shared by all clients, just the data pertinent to each client which may or may not overlap).
To ensure that access is safe, you can always implement classical solutions to the race condition problem. There are algorithms to accomplish this, or you can use mutex locks/semaphores/monitors/etc… or even a queue structure to queue changes to the control system, which ensures no two clients ever modify shared data at the same time
Many options here
The script runs entirely on the server side and clients never have access to it. As such can a race condition still occur? And if so, then I’ll definitely take the mutex approach (seems appropriate in this context). Thanks in advance! : )
1 Like
Clients as in the scripts communicating with the controller, not players - sorry for the ambiguous usage of the term.
As such can a race condition still occur?
A race condition is only going to occur if two of these clients are going to try to write to shared data at the same time - if both clients only read data, there’s no race condition. Is that a possibility in your controller? If it is, then yes, it’s possible. I don’t know how you are communicating with the controller, so I couldn’t tell you exactly when one could occur.
1 Like
If we disregard parallel Luau. Luau’s threading model is single core, meaning only one operation can run at a time, if you dont do any thread control, you can have race conditions on tables.
The best approach is to take a very defensive design on the table and assume nothing is ever defined, which means lots of if statements. If you absolutely need to know the order of operation, you will ironically, need to use an event, or the coroutine/task libraries.
1 Like
Given that I’m using the coroutine library already, I’m assuming you’re referring to the yield method as a way to implement synchronization, right?