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 < brian.armstrong....@gmail.com> 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 <m...@8dio.com> wrote: > >> >> On Feb 27, 2018, at 1:05 PM, Sophia Poirier [dfx] < >> destro...@smartelectronix.com> 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 (Coreaudio-api@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> >> https://lists.apple.com/mailman/options/coreaudio-api/matt%408dio.com >> >> This email sent to m...@8dio.com >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> >> https://lists.apple.com/mailman/options/coreaudio-api/brian.armstrong.ece%40gmail.com >> >> This email sent to brian.armstrong....@gmail.com >> >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
