I'm only familiar with Solaris. In that system the real stuff in a mutex is a byte about 12 bytes into the lock structure. On SPARC the mutex_lock function accesses it with an LDSTUB instruction, which is a special atomic instruction that loads the old value into a register, and stores 0xff into it. If that byte is in the same cache line as some other variable that gets written, and if another processor writes that other stuff, the cache line will be owned by that other processor, and an uncontended mutex_lock can be terribly expensive.
-- David Jacobson David Schwartz <[EMAIL PROTECTED]> wrote: > > Locking with no contention is not "pretty expensive", it's darn near > > free. > On systems with only one processor and nothing like hyperthreading. Did you miss the "with no contention" part? An uncontended lock costs about the same on an SMP system as on an MP system. AFAIK, hyperthreading doesn't affect the cost of uncontended locks. An uncontended lock typically results in one atomic operation (which doesn't actually locked any busses anymore) and possibly one additional cache miss (assuming the lock was recently last held by another CPU). Other costs are totally drowned out by these two. As for a contended lock, it's probably also typically less expensive on a multi-CPU system (though contention is more likely, so it's kind of a bogus comparison). Contention will typically result in more context switches on a single CPU system, and the cost of context switches is enormous compared to the other costs we're measuring here. Hyperthreading likely reduces the cost of a contended lock because the other virtual execution unit gains the use of the execution units the contending thread is not using and contention across virtual execution units in the same core is typically less expensive than across the FSB. I can't think of any obvious reason hyperthreading would have any significant affect on the cost of contention, unless you're talking about broken spinlocks that don't properly relax the CPU (stealing execution resources from the virtual core that's doing useful work). Obviously, broken spinlocks will cause problems on an HT machine, but they should all be fixed by now. In any event, he's talking about a situation where he does everything he can to reduce contention to zero. So the only issues left are what the cost of uncontended locks is (to decide whether it's worth eliminating the locks entirely) and what the consequences are if he misses a case (disaster if he removes the lock, nothing if he doesn't). DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
