Hello..
I wonder if criticalsection is faster than boost::mutex? I guess it is, but is there much difference in preformance?
Printable View
Hello..
I wonder if criticalsection is faster than boost::mutex? I guess it is, but is there much difference in preformance?
What library are you looking at, other than boost?
Critical section is the piece of code in your multi-threaded program that must only be accessed one thread at a time. In other words, any resource that doesn't allow threads to access it concurrently. It is a concept. Not a method.
Boost::Mutex is a way to implement a locking mechanism to your shared resource(s). The type of Mutex and the locking mechnism created around it will determine if your resource is a critical section or not.
it depends on the percentage of the conflicts.Quote:
Originally Posted by l2u
Windows specific:
-------------------------
If conflict are rearly occuring - critical section is better
If the probability of the conflict is high - mutex beats the critical section.
The reason for this is how the OS processes the conflict.
Using mutex - thread changes the state immedeatly and starts waiting for mutext releasing (cahnging state takes several tacs of the processor)
in the critical section - the thread firstly goes to sleep for about 10 processor tacts and checks the state of the section again.
If the section is available - thread continues execution, if the second check failes - only then the thread is suspended (this as I said takes more processor tacs when just 10 tacs sleep)...
So when the conflict is rearly occurs - critical section could never require changing the thread state and becuse of this - beats the mutex.
When the probability of the conflict is high, critical section is performed exactly as mutex, but has an additional waiting loop before entering the suspended state, that mutex version does not have.
I had in mind function(s) InitializeCriticalSection, EnterCriticalSection..Quote:
Originally Posted by Mario F.
I'm not sure about what Vart said. In my opinion, the CRITICAL_SECTION is always faster than a kernel Mutex.
A critical section only spinlocks on SMP systems, i.e. multi-CPU or multi-core systems. It never "puts the thread to sleep for about 10 cycles", because actually putting the thread to sleep already takes several hundred cycles (it's done in kernel mode), not to mention the several hundred more to decide what thread to execute instead. On SMP systems, on a locked CS, the thread will do busy waiting for a bit, hoping that the other CPU will release the CS. On non-SMP systems, it will immediately block.
The thing about the CS is that it doesn't switch to kernel mode just to check whether it is locked and to lock. If the CS is free, it uses atomic operations to immediately lock it without ever entering kernel mode. That's what makes it fast.
Only if it is blocked does it enter kernel mode to sleep until it is released.
A kernel Mutex, on the other hand, enters kernel mode unconditionally. This greatly decreases performance. Because the switch to kernel mode far outweighs whatever other cost the Mutex/CS has, Mutex won't be measurably faster even if every single acquisition blocks first. The only advantage the mutex has is that it works across process boundaries. And can be waited for together with other objects using WaitForMultipleObjects or a related function.
I believe Boost.Threads.Mutex is implemented using a CRITICAL_SECTION, so it would be nearly as fast - the difference would be negligible.
Thanks for that great explanation.Quote:
Originally Posted by CornedBee
So think what will happen when conflict occure so often, that the probability to enter the kernel mode is the same as for the mutex...Quote:
Originally Posted by CornedBee