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: Terry Lambert <email@hidden>
- Date: Tue, 29 Apr 2008 11:21:51 -0700
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:
On Apr 29, 2008, at 8:11 AM, Army Research Lab wrote:
Actually it is of quite a bit of use! My concern about the
OSAtomic*
functions is that they are all defined in libkern/OSAtomic.h. If I
understand Terry Lambert's earlier reply (sent to the list on
Thursday,
April 24, 2008, with the subject 'Re: Where is atomicqueue?'), I
should only
expect to be able to use this within the kernel (Note that that
earlier
conversation was about atomicqueue, and not about the other
functions, so
I'm interpreting what he said, and may be interpreting it
incorrectly.
Terry, please forgive me [and correct me!] if I'm wrong).
I want to be able to use this from user space. Are there any
functions that
are supported from user space and capable of all that the OSAtomic*
functions are?
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.
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).
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.
-- Terry
_______________________________________________
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