Let selector table readers share the lock

[DTW-Thalion]

The selector table is read far more often than it is written. sel_getName, and sel_registerName on a name already known, read it and change nothing, but both took the same exclusive lock as registration.

The lock becomes a read-write lock: a slim reader/writer lock on Windows in place of the critical section, a pthreads read-write lock elsewhere. objc_register_selector_copy read the table through sel_getName while holding the lock, which worked only because the lock was recursive. It reads through sel_getNameNonUnique, which takes no lock and is what register_selector_locked already uses for the same purpose.

Slim locks need Windows Vista. On glibc this is close to a wash, a read acquire costing what the mutex cost, so the Windows figures are what carry it.

Windows at 24 threads, ns per call: sel_registerName on a known name 23871 to 2986, sel_getName 17273 to 2173. One thread is unchanged.

Test/TypedSelectorRegistration.m registers a typed selector whose untyped form is already known, the path that reads the table under the registration lock. Its four cases time out against the recursive call and pass without it. 202 tests pass on Linux, 108 on Windows.

[davidchisnall]

If you're adding this, it's worth doing an audit of the rest of the uses of the LOCK macros. We currently use a recursive mutex for everything, but I think there are actually only two places that should need one:

• The runtime lock (which shouldn't, but I might not have fixed all of the places where it did)
• The locks for @synchronized, which the language specifies to be recursive.

Recursive mutexes add some overhead vs non-recursive ones (especially on Windows: SRW locks are much faster than critical sections in the uncontended case).