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 protected]> wrote: > > On Feb 27, 2018, at 1:05 PM, Sophia Poirier [dfx] < > [email protected]> 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 protected]) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/coreaudio-api/matt%408dio.com > > This email sent to [email protected] > > > _______________________________________________ > 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/brian.armstrong.ece%40gmail.com > > This email sent to [email protected] >
_______________________________________________ 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]
