Re: userland supported APIs (was: Re: Synchronization primitives)
Re: userland supported APIs (was: Re: Synchronization primitives)
- Subject: Re: userland supported APIs (was: Re: Synchronization primitives)
- From: Army Research Lab <email@hidden>
- Date: Tue, 29 Apr 2008 14:35:38 -0400
- Thread-topic: userland supported APIs (was: Re: Synchronization primitives)
On 4/29/08 2:21 PM, "Terry Lambert" <email@hidden> wrote:
> On Apr 29, 2008, at 8:58 AM, Army Research Lab <email@hidden>
> wrote:
>> On 4/29/08 11:20 AM, "Dave Zarzycki" <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden