# Is it safe to set Lua Table data from multiple C++ threads?

As the title states. I'm curious if it's safe to set data in different Lua tables that exist in the same lua state. From multiple C++ threads.

I'm asking this because my current system actually has a separating between Lua's data, and C++'s data, with Lua driving the majority of the game's update and loop - and C++ handling lower level details such as math, rendering, resources, and physics.

After the physics update, I have to waste time in having an entire phase for Lua to update it's own internals for Serialization and grabbing references.

No, Lua's state is not really thread-safe by default, so you can't access the same state from many threads without work on your part.

Lua will call lua_lock and lua_unlock at appropriate points, but by default these methods do nothing and you must #define them to implementations that actually take the appropriate platform-specific critical section.

However, that implements the most bare-bones approach to thread synchronization which just makes sure only one thread is running Lua at a time. You can see here for more information.

A better approach might be trying to reorganize your update loop so something else can happen concurrently with the Lua state sync, which only itself happens on one thread. Perhaps after physics is done processing, you can both synchronize Lua and prepare your graphics calls at the same time? Or something similar; it's admittedly hard to say without knowing more about your architecture.

• Sorry to question-in-comment but, are you saying that it is possible but, basically, not worth it because you can design around the want/need to so easily? (I have no experience with Lua) – Jon Mar 15 '16 at 1:35
• Wait... hold on. What do you mean Lua_lock and Lua_unlock needing to be defined by critical section code? Do you mean that you need to define the interaction somewhere via OS implementation? As in Windows Critical Context, and Linux's Futex? – moonshineTheleocat Mar 15 '16 at 2:21
• @Jon More or less, I'm saying that Lua's basic approach is to take a lock around every access (but only if you provide the code for it to call to take the lock), which is generally the worst possible way to approach concurrency since it's "many threads, but only one touching Lua at a time." – user1430 Mar 15 '16 at 2:25
• @moonshineTheleocat In the link, under the "Locking by Lua" section, they show you an example. The default lua_lock function is #define'd to do nothing. If you want to make it actually take a lock of some sort, you redefine the macro to call some implementation you provide that takes whatever lock you want (so yes, like a Windows critical section). – user1430 Mar 15 '16 at 2:26
• This is pretty curious... Theoretically there's still a benefit to threading in that situation... but it's not optimal because you're writing to a single location. – moonshineTheleocat Mar 15 '16 at 3:45