lua_lock, mutexes, race conditions, update/draw, etc.

[gladius2metal]

Some questions about mutexes, race conditions, etc.
1) Is lua_luck/lua_unlock "implemented"/handled/virtualized/etc. by löve?
2) Are there any other mechanisms in löve or lua that allow mutual exclusive access?
3) Are update() and draw() called sequentially OR are both "performed" in independent threads? (I guess the later or else I shouldn't have a race condition.)


(yeah, I searched the forum before, but the only relevant forum post I found was from 2010 and the internals of löve, but well it didn't help me.)

btw. my current problem: I have a shot, when it travels further than its max range I destroy it (update), but sometimes draw wants to draw it anyway (or access the table element with it) -> crash.

[Roland_Yonaba]

As for the third question, i'll say sequentially.
See the default implementation of love.run here. love.update would always come before love.draw, unless you change love.run behaviour.

[kikito]

My current problem: I have a shot, when it travels further than its max range I destroy it (update), but sometimes draw wants to draw it anyway (or access the table element with it) -> crash.

Are you using some kind of custom LÖVE build with threading added on top of it or something? Otherwise I don't see how adding mutexes etc could help you (LÖVE is single threaded by default, unless you use love.thread, in which case mutexes, etc are not needed since it makes race conditions impossible).

If you show us your code it will probably be much easier to help you.

[gladius2metal]

As for the third question, i'll say sequentially.
See the default implementation of love.run here. love.update would always come before love.draw, unless you change love.run behaviour.

thx, based on that information I was able to track the bug

Are you using some kind of custom LÖVE build with threading added on top of it or something? Otherwise I don't see how adding mutexes etc could help you (LÖVE is single threaded by default, unless you use love.thread, in which case mutexes, etc are not needed since it makes race conditions impossible).

nope, but I added a table.deleteByElement(Table, index) function that set the value to nil instead calling remove (well, and way before I used hump timers, but I got rid of them cause I guess they work with threading

[Robin]

nope, but I added a table.deleteByElement(Table, index) function that set the value to nil instead calling remove (well, and way before I used hump timers, but I got rid of them cause I guess they work with threading

Soo... it wasn't a race condition, then? *puzzled*

[Boolsheet]

Like already mentioned, there's only one Lua state that runs until you decide to create more with love.thread. You should not see threading issues if you never touch that module.

If you use threads, then there is the possibility of a race condition with certain LÖVE userdata. They're shared across Lua states (when passed through the love.thread communication API) and not everything has mutex guards. SoundData for example.

[Inny]

Lua doesn't have a threading model. As far as Lua is concerned, everything is single-threaded. Even coroutines go in sequential order, determined by which call to coroutine.resume happens on what thread objects. LOVE introduces a threading model that's typically referred to as the Actor Model, where all data sharing has to be done through message passing. Meaning that for the most part, you don't need to worry about mutexes and race conditions. Though, you can still create race conditions and livelocks/deadlocks if you're not careful. Before you worry about threading, first see if you can accomplish your goals without threading. If you find things like loading resources and generating procedural content to be wrecking your game's performance, those two are the prime candidates for LOVE's threads to do the work.

[gladius2metal]

nope, but I added a table.deleteByElement(Table, index) function that set the value to nil instead calling remove (well, and way before I used hump timers, but I got rid of them cause I guess they work with threading

Soo... it wasn't a race condition, then? *puzzled*

well, it was a longer process:
1) I used a timer to destroy objects, no problems at first then suddenly problems - then I realized this is probably a race condition problem.
2) I removed the code with the timer.
3) Similar problem occurred, still thinking it was a race condition I did some rewrites, BUT I was assuming that draw() and update() were NOT called sequentially.
4) I was not sure about if it was a race condition after all, but I couldn't find information about draw() and update(), also I did some research about
mutexes in lua meanwhile. This "research" raised some new questions.
5) this thread was born