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.