http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031
--- Comment #5 from Nicola Pero <nicola at gcc dot gnu.org> 2011-01-07 18:23:10 UTC --- I tried the same benchmark using pthread_spin_lock() and pthread_spin_unlock(); it takes about 11.4 seconds. So, that means the time required to execute an accessor can go down to about 67% of the original time by using a pthread spinlock instead of objc_mutex_lock. The spinlock is indeed quite fast, as locking+unlocking seems to take about the same time as an ObjC method call ? That's excellent, but if we were to optimize objc_mutex_lock so that it's as fast as a pthread_mutex, then the spinlock accessor would take about 75% of the mutex accessor, so in the end we are reducing the accessor overhead only by 25% in the best case, while introducing significant unknowns for the worst case. I guess a manual spinlock implementation could be faster than the pthread one, but I expect pthreads to have a good one given writing locks is the reason of existence of their project, so I don't expect we can do that much better than they do. Still, maybe we can inline the function calls, and get it down to 10 seconds or so. Of course, I'm testing on Linux, where IIRC uncontended mutexes are fast as they don't actually do the kernel call unless the lock is actually already locked. Given that Linux is our primary target platform, the case for spinlocks does not seem strong. Presumably Apple uses spinlocks because their primary target platform (Darwin) doesn't have fast mutexes in the way that Linux does ? It would be interesting to test the worst-case scenario for spinlocks to complete the picture. Thanks
