Re: Please test new NSLock implementation!

[David Chisnall]

On 4 Sep 2009, at 08:29, Wolfgang Lux wrote:

> So it looks like David is attempting to optimize code for his platform
> while making things worse for everybody else :-(.

Wolfgang, I have no idea what line of reasoning you followed to arrive  
at this conclusion, but it is simply not true.  The decision to  
include the pthread types as ivars was taken for two reasons:

1) It is conceptually simpler, in code where bugs can be difficult to  
find.
2) It is uses one fewer layer of indirection ON ALL PLATFORMS than  
having a void* pointer pointing to the types, which helps reduce cache  
pressure in multithreaded code (which typically places a lot of stress  
on the cache).

The first of these was the most important reason.  The new code  
implements one more class than the old code, is half as many lines of  
code, actually works on Windows, and is faster.

If you weren't paying attention to the benchmarks I posted a couple of  
weeks ago, the cost of going through the runtime's abstraction layer  
to lock and unlock a mutex is more than the cost of a message send.   
Using the new NSLock implementation is now faster than calling the  
libobjc functions directly (from my microbenchmark, 8.6 seconds  
calling libobjc functions directly, 6.3 seconds calling the new NSLock  
methods, 3.5 seconds calling the pthread functions directly).

On 4 Sep 2009, at 19:42, Scott Christley wrote:

> Why not fix any problems in the ObjC runtime source?

I recently came across a paper which demonstrated several different  
approaches that had been used in open source projects to implement  
condition variables on top of the Win32 API and demonstrated that  
every single one of them was flawed.

If you believe that you can provide a good, clean, and efficient  
implementation, then be my guest and send it along to the GNU runtime  
maintainer.  I'm sure he'll be happy to include some more code in the  
runtime that isn't actually used by the runtime itself anywhere.

Oh, and make sure you add conditional code for when we're compiling on  
Darwin with the Apple runtime.  Actually, that code will be easy,  
because it will be exactly like the code that I've just committed.

The old approach - of including GPL'd code when building on Darwin -  
is simply not acceptable for a project that aims to ship a working,  
cross-platform, LGPL'd, library.

> The point of those interfaces was to hide thread implementation  
> issues across platforms and provide all ObjC programs with thread  
> capability.

The point of the Portable Operating System Interface Standard  
Threading API is to hide thread implementation issues across platforms  
and provide all programs with thread capability.

Unlike the Objective-C runtime abstraction layer, these APIs have been  
widely implemented, widely tested, and are widely supported.  The GNU  
runtime's abstraction layer slow on platforms with pthreads and  
incomplete on most other platforms.  It should never have been made  
part of libobjc; the runtime itself needs mutexes and nothing more.   
Back in the early '90s, it made some sense for the runtime to provide  
this abstraction, but it should have been deprecated back in 1996.

With regard to exposing the ivars; before the next release I intend to  
go through all of the GNUstep headers and wrap the ivar definitions  
(and the pthread.h include) in conditionals like the ones I used in  
NSCache.h so that they are only visible if you are not compiling with  
the non-fragile ABI.

David