Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Mutexes... I need help understanding them
#1
Right. I've looked at the example that comes with fbc, and played around with it, but I still fail to understand completely how they work. I figured it's something about telling other threads not to touch some stuff, but what exactly does mutexlock and -unlock do? One of it waits for a mutex to be unlocked, and then... eh... or does it? yeah, anyone can explain this?
url=http://www.copy-pasta.com]CopyPasta[/url] - FilePasta
Reply
#2
Don't tell me no one knows this...
url=http://www.copy-pasta.com]CopyPasta[/url] - FilePasta
Reply
#3
given that your threads access the same data you have to introduce a mechanism that guarantess that not both threads acess the data "simultaniously". therefor you create a mutex. the mutex is handled by the os and is a singleinstruction thing that can't be interrupted by the mutlithreading mechanism of your cpu/os. now if you have two threads running you lock the mutex in thread one and do your work. while thread 1 does his work he can be interrupted and the current context might be switched to thread 2. thread 2 has to wait no until the mutex is unlocked. so mutexlock is more or less a blocking function that will wait until the mutex is unlocked.

with this mechanism you can make sure that your data doesn't get screwed up. linked lists etc. are pretty sensitive in that respect. so use mutices. you might consider looking up the words mutex or semaphor on wikipedia.
quote="NecrosIhsan"]
[Image: yagl1.png]
[/quote]
Reply
#4
Oki thanks.

So basicly mutexlock waits till the mutex is released, then locks it, and lets execution in that thread continue?
url=http://www.copy-pasta.com]CopyPasta[/url] - FilePasta
Reply
#5
Exactly.

MUTEXLOCK tries to lock the given mutex and if the mutex is already locked, it puts the thread in which it is called in a waiting state. When the lock is free (unlocked by some other thread), the thread in the waiting state locks it and resumes its thread execution.

If there are many threads using the same mutex and doing lock/unlock, only one of them will "own" the mutex lock at any time; when the owning thread calls MUTEXUNLOCK, only one of the other threads sitting in wait state on a MUTEXLOCK call will get the lock and resume execution. Which one you say? Well, that does depend on the system scheduler...
ngelo Mottola - EC++
Reply
#6
Ah. Thanks.

Moving on, what do I need to "protect" with mutexes? rtlib calls? Obviously shared variables, but also when just reading them?
url=http://www.copy-pasta.com]CopyPasta[/url] - FilePasta
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)