Synchronization primitives (was:Re: Where is atomicqueue?)
Synchronization primitives (was:Re: Where is atomicqueue?)
- Subject: Synchronization primitives (was:Re: Where is atomicqueue?)
- From: Army Research Lab <email@hidden>
- Date: Tue, 29 Apr 2008 07:25:08 -0400
- Thread-topic: Synchronization primitives (was:Re: Where is atomicqueue?)
On 4/28/08 3:36 PM, "Terry Lambert" <email@hidden> wrote:
> On Apr 28, 2008, at 4:31 AM, Army Research Lab wrote:
>> On 4/24/08 3:17 PM, "Terry Lambert" <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden