[Top][All Lists]

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

Re: Please test new NSLock implementation!

From: Scott Christley
Subject: Re: Please test new NSLock implementation!
Date: Fri, 04 Sep 2009 11:42:12 -0700

On Sep 4, 2009, at 12:29 AM, Wolfgang Lux wrote:

Fred Kiefer wrote:

What do others think, is it worthwhile to hide these implementation
details via another indirection or not? I am still in favour of using an
opaque data type here. On systems like FreeBSD where pthread_mutex_t is
itself a pointer we could use that directly and on other systems we have
one additional malloc and free call per mutex. And where the structure
fits into your one or two words we could even put the value into the
ivar directly.

I absolutely agree with you here. The interface should not expose any of
the implementation details unless there is a really pressing need to do
so. I understand David's reasoning that the approach with an opaque
pointer may lead to additional cache misses on FreeBSD (and apparently
OpenBSD as well), but without hard figures -- i.e., benchmarks for real
world programs making intensive use of NSLocks that show a substantial
performance improvement -- I consider this kind of coding premature
optimization which should be avoided.

Why not fix any problems in the ObjC runtime source?  The point of those interfaces was to hide thread implementation issues across platforms and provide all ObjC programs with thread capability.


reply via email to

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