many CMutex objects: good idea?
-
Do I pay a penalty for having many mutexes? I am designing a C++ class library and want to set a lock on each object. That is, one CMutex per object and several hundreds of objects (potentially), where only a small number of mutexes will be locked at the same time. I somehow think this might not be a good idea, but maybe I am too pessimistic. Will this work, or will the sheer presence of a large number of mutexes bring Windows to a grainding hold? TIA, Bernd
-
Do I pay a penalty for having many mutexes? I am designing a C++ class library and want to set a lock on each object. That is, one CMutex per object and several hundreds of objects (potentially), where only a small number of mutexes will be locked at the same time. I somehow think this might not be a good idea, but maybe I am too pessimistic. Will this work, or will the sheer presence of a large number of mutexes bring Windows to a grainding hold? TIA, Bernd
A mutex has some kernel data structure associated, so you are "eating up" some ressources. However, if this comes from the nonpaged pool (which is limited) I don't know. But from my understanding, just habving them "hanging around" will not cost you addditional CPU time.
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist || Agile Programming | doxygen -
A mutex has some kernel data structure associated, so you are "eating up" some ressources. However, if this comes from the nonpaged pool (which is limited) I don't know. But from my understanding, just habving them "hanging around" will not cost you addditional CPU time.
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist || Agile Programming | doxygen -
Thanks for your input. I am not so worried about CPU time as I am about system resources. I might be able to use critical sections instead of mutexes (don't need inter-process locking), that should be better in terms of system burden, right?
Not only lighter, but faster. Mutexes are kernel objects, while CS are user-level objects. This means that each operation on a mutex need a costly trip to the kernel, while an operation on a CS doesn't. [stupid-disclaimer] You are hereby notified that any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is strictly prohibited. If you have received this communication in error, please immediately notify the sender and delete this message. No addressee should forward, print, copy, or otherwise reproduce this message in any manner that would allow it to be viewed by any individual not originally listed as a recipient.
-
Do I pay a penalty for having many mutexes? I am designing a C++ class library and want to set a lock on each object. That is, one CMutex per object and several hundreds of objects (potentially), where only a small number of mutexes will be locked at the same time. I somehow think this might not be a good idea, but maybe I am too pessimistic. Will this work, or will the sheer presence of a large number of mutexes bring Windows to a grainding hold? TIA, Bernd
If you don't need the overhead of a mutex, don't use it. Better yet use one of the libraries that provide a lock interface to both objects. That way you can change them easily at a later date. If it is at all possible structure your objects so you can use copies of data instead of sharing, or other approaches to avoid locking as much as possible. Each mutex or critical section you add increases the risk of deadlock and they are very difficult to reproduce and troubleshoot. Also, check out the Objects\Mutexes performance counter object, it will show you a count of all active mutexes. For example I currently have 551 total mutexes on my system.
If you don't kill me you will only make me stronger That and a cup of coffee will get you 2 cups of coffee
-
A mutex has some kernel data structure associated, so you are "eating up" some ressources. However, if this comes from the nonpaged pool (which is limited) I don't know. But from my understanding, just habving them "hanging around" will not cost you addditional CPU time.
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist || Agile Programming | doxygenthat is not completly right peterchen... it will coast you cpu time because a mutex is an object of the windows object manager. that means that every additional object "fills" the list so looking up another object will take more time! Don't try it, just do it! ;-)
-
Do I pay a penalty for having many mutexes? I am designing a C++ class library and want to set a lock on each object. That is, one CMutex per object and several hundreds of objects (potentially), where only a small number of mutexes will be locked at the same time. I somehow think this might not be a good idea, but maybe I am too pessimistic. Will this work, or will the sheer presence of a large number of mutexes bring Windows to a grainding hold? TIA, Bernd
i don't think that this is a good idea at all! what kind of c++ classes are you talking about? how to redesign the code so you don't need mutexes? use one mutex for many similar procedures... there are much better solutions for that! Don't try it, just do it! ;-)
-
Do I pay a penalty for having many mutexes? I am designing a C++ class library and want to set a lock on each object. That is, one CMutex per object and several hundreds of objects (potentially), where only a small number of mutexes will be locked at the same time. I somehow think this might not be a good idea, but maybe I am too pessimistic. Will this work, or will the sheer presence of a large number of mutexes bring Windows to a grainding hold? TIA, Bernd
As already pointed out, using mutexes is an overkill unless the locks are shared between processes. Use a critical section which is much faster but it still creates system objects (an event flag is created when a lock request is blocked.) Having many critical sections can hurt system performance, but not by much. It isn't like NT maintains a link list of system objects and has to cycle though them to locate the system object. I probably uses a O(1) algorithm that is very fast. The question is why do you need many locks instead of one. To answer that, you really need to know how your program is handling threading. If you don't have many threads, what is the chance that two threads will be needing the lock at one time? How long is the lock being held? Will one thread need to acquire more than one lock at a time? The more threads you have accessing these objects and the longer the lock needs to remain locked, the more you need a more granular locking system. Instead of locking the whole object pool, you lock individual objects. Thus greatly reducing the chance of two threads locking the same lock. However, this really only works if the distribution of your objects needing to be locked is spread out. If you have just one or two objects that are being locked all the time while all the others are rarely locked, then this won't help much. As far as needing to have multiple objects locked at one time, if you have this requirement you must start to consider deadlocks. A deadlock happens when thread A locks lock 1. Then thread B locks lock 2. Then thread A requests lock 2 while thread B requests lock 1. Neither thread can continue because each is waiting on a lock already acquired by the other thread. There are multiple ways to handle this. However, dealing with this type of problem is generally nasty. Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
that is not completly right peterchen... it will coast you cpu time because a mutex is an object of the windows object manager. that means that every additional object "fills" the list so looking up another object will take more time! Don't try it, just do it! ;-)
-
As already pointed out, using mutexes is an overkill unless the locks are shared between processes. Use a critical section which is much faster but it still creates system objects (an event flag is created when a lock request is blocked.) Having many critical sections can hurt system performance, but not by much. It isn't like NT maintains a link list of system objects and has to cycle though them to locate the system object. I probably uses a O(1) algorithm that is very fast. The question is why do you need many locks instead of one. To answer that, you really need to know how your program is handling threading. If you don't have many threads, what is the chance that two threads will be needing the lock at one time? How long is the lock being held? Will one thread need to acquire more than one lock at a time? The more threads you have accessing these objects and the longer the lock needs to remain locked, the more you need a more granular locking system. Instead of locking the whole object pool, you lock individual objects. Thus greatly reducing the chance of two threads locking the same lock. However, this really only works if the distribution of your objects needing to be locked is spread out. If you have just one or two objects that are being locked all the time while all the others are rarely locked, then this won't help much. As far as needing to have multiple objects locked at one time, if you have this requirement you must start to consider deadlocks. A deadlock happens when thread A locks lock 1. Then thread B locks lock 2. Then thread A requests lock 2 while thread B requests lock 1. Neither thread can continue because each is waiting on a lock already acquired by the other thread. There are multiple ways to handle this. However, dealing with this type of problem is generally nasty. Tim Smith I'm going to patent thought. I have yet to see any prior art.
Thanks to everybody for mostly constructive input. FYI, I settled on using critical sections, as there is no forseeable need for inter-process locking. I also plan to reduce the number of locks, down from a lock per object to a medium granularity, probably using one lock per class. Again, thanks for input. Bernd