Re: Please test new NSLock implementation!

[Fred Kiefer]

Scott Christley schrieb:
> 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.

The problem there is that the ObjC runtime doesn't include a recursive
lock mechanism. This is one of the strong points in David's code, he
uses the native pthread support for recursive locks, which makes
implementing NSRecursiceLock so much easier. Using pthread directly in
base is OK, but we should hide it from users of base and not spill it on
to user application code.

Fred