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.
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 <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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
