site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: Acip663m7D5QhBXeEd23XAAdT0T19A== Thread-topic: Synchronization primitives (was:Re: Where is atomicqueue?) User-agent: Microsoft-Entourage/11.4.0.080122 On 4/28/08 3:36 PM, "Terry Lambert" <tlambert@apple.com> wrote:

On Apr 28, 2008, at 4:31 AM, Army Research Lab wrote:

...

On 4/24/08 3:17 PM, "Terry Lambert" <tlambert@apple.com> wrote:

...

Short answer:

(1) It's protected by #ifdef __ppc__, so it's PPC only

(2) It's in a header <libkern/OSAtomic.h>, so you should only _expect_ to be able to use it in the kernel; the fact that there are some inline functions there notwithstanding

(3) The atual implementaiton is as an external symbol in the Libkern and System6.0 exports for PPC only

So to get at it you will need to be linked against the kernel (you will need to be either kernel code or a KEXT), you will need to be running PPC-only, and you will need to declare an explicit dependency for your KEXT on an exported symbol set or on the entire kernel.

OK, are there spinlocks in user space? I want to try a couple of experiments with some code, just to see if pthread_mutex_lock() is better, or if spinlocking is better.

If you use

nm /usr/lib/libSystem.B.dylib

you can probably answer these questions for yourself.

Good point. And, yes, I see now that spin_lock(), spinlock_try(), and spin_unlock() are defined. I still haven't found the headers for them, but I figure that's just a matter of time (unless they aren't supported).

For things for which there are not exported prototypes in header files, there is no explicit support for them. So technically, i386 has OSAtomicEnqueue(), spin_lock(), et. al., but they are not supported, as such. You can see their source code in the published Darwin Libc sources.

Understood. And if I can't find the headers for them, I won't bother with them.

The pthread_mutex() is going to be heavier weight than spin locks, but spin locks spin, which means they will meaninglessly burn CPU cycles, so "better" is really going to depend on your definition; if you care about battery life and hold them a long time, the answer will be "no", and if you are single CPU, the answer may be "they will just cause you to deadlock". Any spin lock you use, or OSAtomicEnqueue, etc., is probably not going to be desirable to use in any PTHREAD_SCOPE_SYSTEM rather than PTHREAD_SCOPE_PROCESS object.

I understand the problems with them; however, the case I plan on supporting generally locks for just long enough to write a value to a shared location, with the values being 32 or 64 bit ints. That was why I got interested in the various atomic functions. I know that they have a much higher likelihood of being optimized than using pthread lock/write/unlock.

I would recommend you restrict yourself to supported interfaces.

I don't plan on doing otherwise. If I can't find a supported interface for it, then I'll have to find another way.

Also, if you want to take an atomicqueue discussion and go off talking about spin locks, you probably ought to either change the subject to reflect a general interest in synchronization primitives, or to explicitly talk about that instead, or the information isn't going to be indexed properly and someone coming after you is just going to ask the same questions again.

My apologies. 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