Mutex
BlitzMax Forums/BlitzMax Programming/Mutex
| ||
| I'm not getting this Mutex & LockMutex thing. How many Mutexes can be created? Does one LockMutex lock all the variables a thread is using? Jim |
| ||
| Does one LockMutex lock all the variables a thread is using? As I understand it, a mutex doesn't actually "lock" anything. You would normally manually set/check the status of a mutex before executing threaded code. See TryLockMutex(). |
| ||
| You can create as many Mutexes as you need. They actually block entire thread execution if another thread has a lock. For example: -If you have thread "A" that writes the value of a variable, and -you have thread "B" that reads the value of a variable, -then you don't want thread "A" writing to that variable while thread "B" was reading from it (the read may happen while the individual bits are being changed at a low level) So, if thread "A" were to lock before writing, and unlock after writing, then when the lock were called from Thread "B", execution would halt until thread "B" received its lock (locks happen in-turn). The reason why you can have multiple Mutexes is that if you only had one, and you used it for 2 variables, then there would be times that execution could be blocked while thread "A" was writing to variable 1, and thread "B" was reading/writing to variable 2. So essentially, the Mutex its self doesn't lock any specific block of memory or resource.. Its in how you use the mutex (where yo ucall lock and unlock in all threads) that determines what area of memory is protected. For example... If you have a variable called speed:int, and you make a mutex called lockSpeed:TMutex... You could technically lock and unlock lockSpeed:TMutex anywhere in the program, but in actuallity what you would want to do is call LockMutex(lockSpeed) in any thread before reading/writing to speed:int, then call UnlockMutex(lockSpeed) when finished. This will ensure all threads respect eachother when reading or writing to speed:int |
| ||
| Concept Example that isn't really applicable to the real world but might give you an idea. I have a mutex for moving the leader of the bad guys in my game. I lock it before I move the leader and unlock it when he's done moving. All of the lower level bad guys Check to see if the leader is locked before they move. This prevents them from moving at the same time and being stepped on by the leader. A more real world example is when modifying a TList You lock a mutex associated with the Tlist when you interact with it in any way (add/remove/iterate through). This prevents something from being removed from the list in 1 thread at the same time that the list is being looped through in another thread. Since the both lock before they start their task, and unlock when they're done the first thread to get there gets to do it's thing and finnish it up safely before the next thread has a go. It's a safety catch to keep threads from stumbling over each other. |
| ||
| Thanks guys, I hopefully understand better now! Jim |
   |