[Bug libobjc/47031] libobjc uses mutexes for properties

["js-gcc at webkeks dot org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031

--- Comment #3 from js-gcc at webkeks dot org <js-gcc at webkeks dot org> 2011-01-01 12:06:56 UTC ---
> The problem is that property accessors are basically general purpose routines
that may be used in the most varied situations.

It does not matter very much in which situation a property is used. To chose
which type of lock you use, it's only important what is done while the lock is
held. In this case, no call to the kernel-space is made at all and only a small
operation is done. Switching to kernel-space for a mutex is already way more
complex than what we do in the lock. If I'd have to guess, I'd say switching to
kernel-space is at least 100 times more expensive than what we do.

> So, we have very little control or knowledge over when and how they are used --

Which we don't care about at all.

>  * we don't know how many CPUs or cores the user has

Does not really matter. If we have two cores, the spinlock can give control to
another thread after 10 spins using sched_yield().

So, if we only have one core and one thread spins because it waits for another
core to release the lock, then we waste at maximum 10 tries. This is the
worst-case scenario.

If we have more than one core, we most likely have another thread releasing the
lock before it even spinned 10 times.

So, no matter how many cores, it does not perform worse than a mutex (at least
not in a measurable way), while on systems with many cores, it's a huge
improvement. Plus changing a property is something that's so fast that we most
likely will never encounter a locked spinlock. That'd only happen if the
scheduler gave control to another thread before the property was changed.

So, with spinlocks, in 99% of the cases, it's not even measurable.
With mutexes, in 100% of the cases, it IS measurable.

>  * we don't know how many threads the user is starting
>  * we don't know how many threads are sharing a CPU or core

We don't really care about them, I think.

>  * we don't know how intensively the user is using the property accessors

So, because we don't know how intensively the user is using properties, we will
make them slow on purpose?

> Spinlocks are appropriate when certain conditions are met; but in this case,
> it seems impossible to be confident that these are met. 

Which conditions are not met in your opinion? Please list the conditions that
you think are not met, as Apple clearly thinks they are all met. And so do I.

> A user may write a
> program with 3 or 4 threads running on his 1 CPU/core machine, which constantly
> read/write an atomic synthesized property to synchronize between themselves. 
> Why not; but then, spinlocks would actually degrade performance instead of
> improving it.

This is actually why you call sched_yield() after 10 spins. It prevents a
thread from being stuck spinning while another thread could release the lock.


> Traditional locks may be slower if you a low contention case, but work
> consistently OK in all conditions.

Yes, they are the same in all conditions because they are always more complex
and slower ;).

> * spinlocks are better/faster if there is low contention and very little
> chance that two threads enter the critical region (inside the accessors) at the
> same time.

This is the case here.

> * the difference in performance between mutexes and spinlocks only matters in
> the program performance if the accessors are called very often.

If you init a lot of objects and those initialize let's say 30 variables using
properties, then this means that 30 locks are retained and released, although
no other thread could possibly access it. But still you do 30
userland-kernelspace-switches. For a single object! Now create 1000 objects.

With spinlocks, there won't be a single userland-kernelspace-switch!

Just to demonstrate that we are talking about something which really can make a
huge difference…

I think the percentages you list cannot be used at all, as we don't have
applications just doing some math calculations and then quitting. We don't want
something slow just because it might only be a small part of the program. We
want everything to be as fast as possible. Otherwise it sums up and makes a
crappy user experience for interactive applications. Apple demonstrated this
quite well if you compare how crappy it felt a few years ago and how well it
feels now that they started optimizing the small stuff as well.

> The only case where spinlocks really help is if the program spends lots of time
calling accessors, and is not multi-threaded.  In which case, the programmer
could get a huge speed-up by simply declaring the properties non-atomic.

Even in a threaded environment, it would make a huge difference. It's unlikely
the lock is held. Only if it is held, you need some CPU time. But with Mutexes,
each time you only check if the lock is held, you already switch to
kernel-space.

> Would using spinlocks make
> accessors 2x faster ? 10x faster ? 10% faster ?

My guess is that usually the spinlock is not held, so I could imagine factor
100 faster or even factor 1000. I remember having had some test some while ago
where I tried just locking and releasing a mutex and a spinlock and doing one
arithmetic operation. While the version with spinlocks took only a few seconds,
the version with mutexes still was not finished after a few hours, which was
when I aborted it.