[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please test new NSLock implementation!

From: David Chisnall
Subject: Re: Please test new NSLock implementation!
Date: Fri, 4 Sep 2009 20:57:11 +0100

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]