3

In every tutorial about mutex, mutex is described as a way to prevent for example multiple threads to access the same resources at the same time. But what are those resources. I know that the resources can be a lot of things, like for example variables, but how do i define those variables that shouldnt be used at the same time by another thread? How does Mutex know which variables to "lock"? I dont understand how the compiler can know before executing the code what Mutex should lock between the functions mutex.lock and mutex.release.

273K
  • 29,503
  • 10
  • 41
  • 64
Dennis Hotca
  • 39
  • 2
  • 1
    It's usually an OS construct. Related: [https://stackoverflow.com/questions/1485924/how-are-mutexes-implemented](https://stackoverflow.com/questions/1485924/how-are-mutexes-implemented) – drescherjm Sep 29 '22 at 13:58
  • 11
    Mutex doesn't know anything about other variables. It is locking itself. That is, the underlying OS will know that a process that is trying to acquire a locked mutex should not be scheduled in, that is - should be suspended. So the code *after* the lock attempt will not execute and any "resources" that are used there won't be used until the mutex is unlocked by the locking process. – Eugene Sh. Sep 29 '22 at 14:01
  • 2
    The mutex protects what you choose it to protect. As long as you always only access the resource(s) you intend to protect while holding the given mutex, then those resources will be protected against concurrent access. But if you forget and access one or more things *anywhere* where you *should* have locked the mutex, but didn't, then you have a data race. So it's all under your control. – Jesper Juhl Sep 29 '22 at 14:06
  • 2
    The use of a mutex constitutes a *protocol* to which all participating accessors of the shared resources must adhere. Kind of like how holding an object in your hand indicates that you're using it and nobody else should try to use it at the same time as you. But if you have a hungry dog that doesn't respect this protocol, then you well imagine how you still might not get the controlled access to your sandwich that you intended. – Wyck Sep 29 '22 at 14:22

1 Answers1

3

The answer depends on how you want to think about it.

At a low level, a mutex locks nothing but itself. Two threads will never be allowed to lock the same mutex at the same time. End of story.

At a higher level, a mutex locks whatever data you want to lock with it. A mutex is a type of advisory lock. It's like a sign hanging on a door knob that says, "in-use, do not enter." It will keep out whoever respects the sign, but it has no actual power to keep anybody out.

If you have some data shared by several threads, and if you don't want any two threads to ever access* the data at the same time, then you can set up a mutex, and declare that, "None shall access these data unless they have the mutex locked." That declaration is what @Wyck called a "protocol" in a comment, above.

It's up to you to ensure that no thread in your program ever accesses the data without holding the mutex locked. I.e., it's up to you to ensure that your code obeys the protocol.

Also note! Nowhere did I mention "method" or "function." There's never any inherent benefit to locking a method or a function. It's always about the data that the method or the function accesses.

* "Access" doesn't just mean "update." If one thread merely tries to read the data while some other thread is in the middle of updating it, the reading thread could see an inconsistent or invalid snapshot of the data, and it could make arbitrarily bad decisions based on what it saw. The consequences could be fatal to the process, or worse.

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57