Are memmove and malloc thread safe?

Question

I have some code that moves bytes in a buffer using memmove(). The buffer is accessed by multiple threads. I get a very weird behavior; sometimes the buffer it's not what it should be and I was thinking if memmove() or/and malloc() are thread safe. I'm working on iOS (in case this is platform dependent).

Internets +1: I googled your question and StackOverflow came up: http://stackoverflow.com/questions/855763/malloc-thread-safe — adam_0, Apr 06 '11 at 17:52

score 6 · Accepted Answer · answered Apr 06 '11 at 17:57

In an implementation that provides threads, malloc will normally be thread safe (i.e., it will take steps to assure the heap doesn't get corrupted, even if malloc gets called from multiple threads). The exact way it will do that varies: some use a single heap, and internal synchronization to ensure against corruption. Others will use multiple heaps, so different threads can allocate memory simultaneously without collisions.

memmove will normally be just like if you did assignments in your own code -- if you're sharing a buffer across threads, it's your responsibility to synchronize access to that data.

score 3 · Answer 2 · answered Apr 06 '11 at 18:07

3

You should be using a mutex (NSLock) as a protective barrier around accessing your buffer. Take a look at Synchronization in Apple's Threading Programming Guide.

answered Apr 06 '11 at 18:07

Black Frog

11,595
1
35
66

score 2 · Answer 3 · answered Apr 06 '11 at 17:51

2

Malloc may be thread-safe. The standard doesn't require it, but many C compilers are used in systems whose applications requires thread safety, and your particular compiler's library may be thread safe, or offer a thread safe option. I don't know about iOS.

Memmove (or any other kind of block move) is not thread safe, any more than an assignment statement is thread safe.

answered Apr 06 '11 at 17:51

Ira Baxter

93,541
22
172
341

2

Every threading specification for C I've ever seen requires `malloc` to be thread-safe, and of course the upcoming C1x standard will. `memmove` is also thread-safe in the normal definition of thread-safe, which excludes using it to modify the same object from multiple threads simultaneously. – R.. GitHub STOP HELPING ICE Apr 06 '11 at 18:18
@R: Every? The compiler vendor does something, and yes it is popular but it isn't a requirement. MSVS's malloc isn't thread safe unless you pick the right library. I thought I was clear about memmove being the same as assignments. – Ira Baxter Apr 06 '11 at 19:10

score 1 · Answer 4 · answered Apr 06 '11 at 18:21

Since the current C standard does not specify threads, it has nothing to say about thread safety. Whenever you have threads, you're dealing with a system that has placed further requirements, beyond the basic C language standard's requirements, on how the standard library functions behave. I'm not sure what requirements iOS makes, but POSIX and Windows both require malloc to be thread-safe, and I'd find it hard to believe any system designed after the mid 90s would not make this requirement.

Note that the upcoming C1x standard will specify threads, and if the implementation has threads, then malloc will be required to be thread-safe.

score 0 · Answer 5 · answered Apr 06 '11 at 17:49

0

No, since the standard C library doesn't have a concept of threads, the functions it defines can't be.

answered Apr 06 '11 at 17:49

unwind

391,730
64
469
606

I see, so basically NO functions are thread safe in C (standard)? Good to know! I think this IS my problem then! – Rad'Val Apr 06 '11 at 17:51
@mindnoise: the C standard isn't thread-aware, but since most of the current CRT implementations are used in multithreaded environments, each specific compiler usually gives particular guaranties about what is and what isn't thread-safe in the standard library. – Matteo Italia Apr 06 '11 at 17:54
OK, that means that I have to find out if in Objective-C/iOS they are or not, although judging after the comments, I think not. – Rad'Val Apr 06 '11 at 17:58
Functions that don't operate on some kind of shared static (non-stack) state might be safe, stuff like strtol() for instance. – unwind Apr 06 '11 at 18:06
@unwind - even then you can't rely on it unless the vendor says they are. Even strtol has internal state as it parses the string. – Martin Beckett Apr 06 '11 at 18:08
1

@Martin: of course it has state, but I would expect that to be on the stack, so two threads running the same code would have no data in common. That's what I meant, I'll edit for clarity. – unwind Apr 06 '11 at 18:09
@unwind - almost certainly true. But subtle are the ways of compiler and library writers - you can't trust em! – Martin Beckett Apr 06 '11 at 18:15

Are memmove and malloc thread safe?

5 Answers5