Best way to implement a mutex lock?

Help and Feedback Scripting Support
#1

I need a mutex lock for something; What’s the best way to implement one in roblox?
Infact, is it even possible?

#2

It’s not a feature of the Roblox engine, however depending on your code and what you want to do exactly, making your own custom mutex system wouldn’t be impossible.

#3

A mutex is just an agreement to wait until the resource is unused. Doesn’t have to be complicated.
You could probably create an object with a few methods and a boolean, and share an instance of the object between the scripts requiring the resource via a ModuleScript.

mutexObj:lock() -- Waits until mutexObj is unlocked before locking it and resuming execution
-- Do processing with shared resource
mutexObj:unlock() -- Unlocks mutexObj

If all of your code around this resource follows this agreement, you have an effective mutex.

2 Likes
#4

The issue with this is that there is no guarantee the mutex lock and unlock methods will be threadsafe themselves.

You need some atomic test and set operation; Is there any equivalent in lua?

#5

Roblox runs all Lua on a single thread, so you don’t need this guarantee.

4 Likes
#6

Came here to say this. Lua is single threaded so as long as you don’t do anything in your mutex locking methods that could allow another thread to start executing (wait, waitForChild, ect.), you’ll be fine.

1 Like
Is this mutex lock implementation correct?
#7

I’m not entirely certain, but I believe that all Lua threads are thread-safe globally, because of how the scheduler works. Here are some assumptions I can come up with, which may or may not be true:

  • All Lua threads are managed by the singular Lua scheduler.
  • The scheduler itself is thread-safe.
  • All async C-side operations must communicate with Lua through the scheduler.
    • For example, when a C-side event is triggered, it cannot resume a waiting thread itself; it must mark the thread to be resumed slightly later by the scheduler.
  • The scheduler runs, at most, one Lua thread at a time.

Last I checked, there are multiple schedulers, but I don’t know if there are more than one that manage Lua threads. I’m also not sure how security identities are handled here. That is, they might run on their own isolated schedulers, which may or may not be synchronized with each other so that the one-thread-at-a-time remains true.

Anyway, for all intents and purposes, mutexes are not necessary for this case, as there are no threads running in parallel.

3 Likes
#8

For lesser beings such as myself who didn’t know what a mutex lock was: https://en.wikipedia.org/wiki/Mutual_exclusion

As a quick synopsis, its a schedular that makes sure threads don’t have race condition bugs (i.e You create a function at the same time you call another function, but the first function sometimes executes after the second, but the second is dependant on the first, causing it to break), by preventing threads reaching the critical stage at the same time

1 Like
#9

Essentially, yes.

Also look into semaphores if you are interested in this kinda stuff! Super useful in operating system design.