site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: AciqJ9HHEELMbhYbEd23XAAdT0T19A== Thread-topic: userland supported APIs (was: Re: Synchronization primitives) User-agent: Microsoft-Entourage/11.4.0.080122 On 4/29/08 2:21 PM, "Terry Lambert" <tlambert@apple.com> wrote:

On Apr 29, 2008, at 8:58 AM, Army Research Lab <ckaran@arl.army.mil> wrote:

...

On 4/29/08 11:20 AM, "Dave Zarzycki" <zarzycki@apple.com> wrote:

...

We, Apple, have made a small confusing mess when it comes to OSAtomic.h. Both userland and kernel-land have a header by that name. Unfortunately, not all of the API within have the same names, with the same arguments. The userland header is located here: /usr/include/ libkern/OSAtomic.h and is supported API.

Does that mean that anything I find in /usr/include is supported in userland? I mean, what Terry said made a lot of sense to mean, that since it is in libkern, we shouldn't use it. So, is there anything we should stay out of in /usr/include when in userland?

I was specifically referring to OSAtomicEnqueue() et. al., which is protected away from general public use by being limited to __ppc__, and by not having prototypes in scope internally for the non-inline i386 libSystem.B.dylib implementation.

I was also obliquely referring to the rather large mess that Dave Z. pointed out so bluntly.

I personally have a real problem with libkern headers from xnu being overloaded the way they have been, given that people link against neither the kernel nor against libkern (what in other systems might be called libstand, and used for stand alone bootable programs designed to allow them to be loaded directly by the OS boot loader in place of mach_kernel). Header prototypes are intended as contracts for specific external inkages, and inline functions are supposed to be an implementation detail.

Dave Z. is right about the mess, and my oblique reference was sort of a warning to let you know that someone like me (and, it looks like, Dave Z.) may come along and clean it up out from under you at some point to improve our own opinions of system esthetics.

Ah. In that case, I'll stay out of there.

For the OSAtomicEnqueue() etc. itself, although this sort of thing _can_ be used safely, and Linux externalizes something like it, it's got some serious limitations, and there is a nice paper by IBM on Linux's implementation that implies that lockless queueing can't be safely used under certain circumstances on Intel-based multiprocessor systems. That's a hidden constraint that not every programmer will deal with correctly, leading to really subtle bugs. The paper is mildly controversial, to say the least (there are a lot of people who would really like lockless queue and list management to be possible, even if it isn't, and wishful thinking sometimes overrides even the best engineers judgement).

Do you know the name of the paper? I'd like to read it.

As far as exposed prototypes in public headers meaning "supported", we're human and we make mistakes, too. Trust the documentation you've been pointed to by Shawn E. and others more than the header files.

Like I said before, no problem. I just want to have a definitive answer before I start relying on something that goes away. So, to recap my understanding of all this: 1) It is possible to use stuff in /usr/include/libkern, but... 2) ...don't do that! It may/probably will go away at some point in the future as cleanup occurs. 3) There isn't anything quite like the OSAtomic* operators in user space that are truly supported (that is, won't be removed in the future during cleanup), and therefore if I want shared variables, I need to use pthread_mutex_lock(), write my variable, and then unlock(). Am I wrong about any of this? Thanks, Cem Karan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com