1

I have a C library which I'm cross-compiling to use in Android & iOS apps.

It makes use of memcpy() and mktime() so I want to know if these functions are implicitly thread-safe when used in multi-threaded environments.

iOS apps compiled with modern Xcode and Android libraries compiled with modern Android NDK use a clang compiler which is LLVM-based.

I've reviewed the following questions, but have been unable to find a definitive answer:

DaveAlden
  • 30,083
  • 11
  • 93
  • 155

2 Answers2

4

POSIX requires of conforming implementations that all functions it standardizes be thread safe, with the exception of a relatively short list of functions. memcpy() and mktime() are both covered by POSIX, and neither is on the list of exceptions, so POSIX requires them to be thread safe (but read on).

Note well, however, that this is not a matter of the compiler used, but rather of the C library that supports your application. I recall Apple's C libraries being non-conforming in some areas. Nevertheless, there's nothing in particular about memcpy() and mktime() that makes them inherently risky from a thread safety perspective. That is, there's no reason to expect that they access any shared data, except any provided to them via their arguments.

And there's the rub. You can rely on memcpy() and mktime() not to, say, rely internally on static data, but POSIX's requirement for thread safety does not extend to working as documented in the face of data races you create through choice of arguments. Thus, for example, if two different threads call memcpy(), and the target region of one call overlaps either the source or target region of the other, then you need some flavor of synchronization between the threads.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • Great, this is useful (as is the answer from @Ctx). I'm reading this to mean, so long as I don't do anything stupid with these functions or run them across multiple threads (the implementation I have only operates on a single thread) then I should be OK. I guess Crashlytics data will tell me otherwise once it goes live :-) – DaveAlden Jul 03 '18 at 16:18
  • @DaveAlden, what's "stupid" may be subjective, but basically, yes. In particular, as long as the destinations of all your `memcpy()`s and `mktime()`s are local variables, you should have nothing to worry about. And to the extent that the destinations are provided by your library's callers, it is mostly not your problem. It's also not an issue when your library is used concurrently by different apps. – John Bollinger Jul 03 '18 at 18:59
2

The question if memcpy() is thread-safe might be discussible.

I would say that memcpy() is indeed thread-safe. It doesn't rely on a (global) state, which could be mangled up by multiple instances of memcpy() running. This, however, doesn't mean, that there is some magic preventing a memory area, which is concurrently the copy destination of multiple threads doing memcpy() gets badly mangled up, i.e. the copy process as a whole is not atomic. You would have to care yourself using mutexes to ensure atomicity.

mktime() is trivially threadsafe, since it doesn't use static buffers, use a global state or similar. The manpage mentions a few functions from that family being not threadsafe (those have corresponding *_r functions), but mktime() is not amongst those.

Ctx
  • 18,090
  • 24
  • 36
  • 51