Re: Any system calls OK to use in audio thread?
Re: Any system calls OK to use in audio thread?
- Subject: Re: Any system calls OK to use in audio thread?
- From: Brian Armstrong <email@hidden>
- Date: Tue, 27 Feb 2018 22:10:59 +0000
Also, in the context of things that could block, it's certainly possible
that reading/writing to a large array will hit an unmapped page, which I
believe will context switch your thread out. I don't know that any OS makes
guarantees for how long a page fault could take. I think it's not generally
possible to make such guarantees with virtual memory.
So tldr - if you want to have an audio thread, only run it in an RTOS with
no virtual memory and all interrupts disabled. Anything else is asking for
trouble ;)
On Tue, Feb 27, 2018 at 2:08 PM Brian Armstrong <
email@hidden> wrote:
> Thread-safe in this context might mean it's reentrant? Which you'd
> certainly hope is true for memcpy, but, you never know :P
>
> On Tue, Feb 27, 2018 at 1:45 PM Matt Ingalls <email@hidden> wrote:
>
>>
>> On Feb 27, 2018, at 1:05 PM, Sophia Poirier [dfx] <
>> email@hidden> wrote:
>>
>> What would memcpy even be locking to protect/serialize? The caller
>> provides all of the data used in the function. So if the data needs
>> serialization with other threads, that is the caller's responsibility.
>>
>>
>> made no sense to me.. but I’m just being paranoid.
>> Looking at the source does put it to rest — thanks for the link.
>>
>> -m
>>
>>
>> By the way, any libc and libc++ library functions have open source
>> implementations for most compilers. Here you can confirm memcpy lack of
>> locking on Apple platforms:
>>
>>
>> https://opensource.apple.com/source/xnu/xnu-2050.18.24/libsyscall/wrappers/memcpy.c
>>
>> - Sophia
>>
>>
>> On Feb 27, 2018, at 12:00 PM, Matt Ingalls wrote:
>>
>>
>> OK thanks
>>
>> I would be very surprised if memcpy() were on a list of functions that
>> lock.
>>
>>
>> Yeah me too, but I wanted to be absolutely sure.
>> Even googling “memcpy thread safe” came up with a(n unverified) comment
>> that it IS on Solaris, which probably means it takes a mutex, right?
>>
>> Perhaps my question here really should have been: “where can I find a
>> list of common functions that never lock?” :)
>>
>>
>> dispatch_async() is completely different from vDSP.
>>
>>
>> Well I said that to say if dispatch_async isn’t lock-free, then that
>> means GCD isn't entirely either.
>> And the (typically vague) apple documentation says "many vecLib routines
>> used multiple POSIX threads...In OS X v10.7, these routines use Grand
>> Central Dispatch”
>> And since vDSP is part of vecLib…what else can I conclude?
>>
>> -m
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden