Thanks for that explanation. I was just reading how a lock can turn bad also when there's an exception after locking. I believe the suggestion I read there could help in this situation, too: to have a separate class that just locks all needed mutexes in its constructor and unlocks them in its destructor. If I understood correctly, the destructor is still called even if there's an exception. But it seems this would also take care of forcing all locking to be done in the same order. At any rate, the problem you described here is one I'd never considered before, and you made it very clear.
Hey Dave, could really use your help. I've followed your Lua tutorials and everything is working great! I recently added multithreading capabilities to my software to make it faster, however as soon as I hook up Lua to the multithreaded workers (24 of them), everything is as slow (if not slower) than if it were limited to 1 thread. Each worker has it's own Lua script object (and state), yet it doesn't appear to actually be running multithreaded? Any ideas?
Well 24 workers is a lot, do you actually have 24 hardware cores on your machine? Mine only has 16 and its really 8 + 8 "hyperthreads" that aren't really cores at all. So perhaps all the context switching between the threads is causing them to run slower, A context switch count end up being many orders of magnitude slower than the operation you are trying to complete on the thread.
Very useful! I don't understand only a thing. In the last solution you found, didn't you lose advantages of multithreading? The two thread are processed one at the time, isn't it?
That is true, in that example only one of threads is actually managing to get at work done at once. However, what is happening is that the work can be done by either of the threads, and they are not going to deadlock each other (so it is multhreaded, but it is has bad concurrency) . In a real world scenario, they may be more then 2 locks invovled but you might only require 2 to do your work, so in theory multithread work could still happen. One example might be say you had an 8x8 tiled board, like a chessboard, and each tile in the board has a lock on it when you want to move a piece. If you ever wanted to move something from one tile to another, then you have to take the lock on both of the tiles (the one you are moving from, and the one moving to), other threads could also be doing the same thing, but as long as they are not moving pieces to or from the same tile as you then the work can happen concurrently. If you take the locks in the correct order then the threads will not deadlock each other.
Your videos are always top notch. Thanks!
Thanks for that explanation. I was just reading how a lock can turn bad also when there's an exception after locking. I believe the suggestion I read there could help in this situation, too: to have a separate class that just locks all needed mutexes in its constructor and unlocks them in its destructor. If I understood correctly, the destructor is still called even if there's an exception. But it seems this would also take care of forcing all locking to be done in the same order.
At any rate, the problem you described here is one I'd never considered before, and you made it very clear.
This video is very clear, thank you.
Thank you very much for the amazing explanation 👏
Hey Dave, could really use your help. I've followed your Lua tutorials and everything is working great! I recently added multithreading capabilities to my software to make it faster, however as soon as I hook up Lua to the multithreaded workers (24 of them), everything is as slow (if not slower) than if it were limited to 1 thread. Each worker has it's own Lua script object (and state), yet it doesn't appear to actually be running multithreaded? Any ideas?
Well 24 workers is a lot, do you actually have 24 hardware cores on your machine? Mine only has 16 and its really 8 + 8 "hyperthreads" that aren't really cores at all. So perhaps all the context switching between the threads is causing them to run slower, A context switch count end up being many orders of magnitude slower than the operation you are trying to complete on the thread.
My program is not recognizing threads ,Please tell what i can do to it
Very useful! I don't understand only a thing. In the last solution you found, didn't you lose advantages of multithreading? The two thread are processed one at the time, isn't it?
That is true, in that example only one of threads is actually managing to get at work done at once. However, what is happening is that the work can be done by either of the threads, and they are not going to deadlock each other (so it is multhreaded, but it is has bad concurrency) . In a real world scenario, they may be more then 2 locks invovled but you might only require 2 to do your work, so in theory multithread work could still happen. One example might be say you had an 8x8 tiled board, like a chessboard, and each tile in the board has a lock on it when you want to move a piece. If you ever wanted to move something from one tile to another, then you have to take the lock on both of the tiles (the one you are moving from, and the one moving to), other threads could also be doing the same thing, but as long as they are not moving pieces to or from the same tile as you then the work can happen concurrently. If you take the locks in the correct order then the threads will not deadlock each other.
@@DavePoo Thanks, I think I've understand now.
just use std::atomic lol