ConcurrentLock Benchmarks

Critical Section

By using "Critical Section" as a locking mechanism, all threads are guaranteed access, but the time for access can be noticably long; thus causing poor application response time. This can also cause other normal mutexes and semaphores to timeout.

Mutexes

By using "Mutex" as a locking mechanism, all threads are NOT guaranteed 100% access, but the time for access is defined progammatically to ensure for good application response time. However, unless the application is written to expect mutex timeouts and can still complete its task, it can produce unexpected application behavior. Up to now, this has been the best alternative to locking.

ConcurrentLock

By using "Concurrent Lock" as a locking mechanism, like mutexes, all threads are NOT guaranteed 100% access, and the time for access is defined progammatically to ensure for good application response time.

However, it tries to accomplish the best of both worlds, providing a success rate (if tuned properly) almost as good as critical sections, and as good a response time as mutexes. Also, notices the number of accesses that each type of thread serviced... 3 times more than CriticalSections, and 5 times more than Mutexes !!!
SourceForge Logo