Is memcpy process-safe?

Question

Ive looked online and have not been able to satisfy myself with an answer.

Is memcpy threadsafe? (in Windows)

What I mean is if I write to an area of memory shared between processes (using boost::shared_memory_object) using a single memcpy and then try read that area from another process using a single memcpy then will one process be blocked automatically while that write is happening? Where can I read about this?

Threads and processes are different things. – user2357112 Apr 07 '14 at 09:53 — user2357112, Apr 07 '14 at 09:53

John Källén · Accepted Answer · 2013-02-28T20:51:33.260

12

memcpy is typically coded for raw speed. It will not be thread safe. If you require this, you need to perform the memcpy call inside of a critical section or use some other semaphor mechanism.

take_mutex(&mutex);
memcpy(dst, src, count);
yield_mutex(&mutex);

edited Feb 28 '13 at 20:51

answered Feb 28 '13 at 20:38

John Källén

7,551
31
64

1

Yes you should use your own locking. But because you are operating on shared memory, not because `memcpy` is not thread safe. – not-a-user Nov 14 '13 at 16:51
@temple: nothing in the manual says it is, so it is not :) http://linux.die.net/man/3/memcpy – Drakosha Nov 14 '13 at 22:20
This answer is incorrect. [In Windows there are C runtime libraries that are threadsafe](http://stackoverflow.com/questions/2278919/are-the-time-functions-of-msvc-thread-safe). memcpy is threadsafe under Solaris. – Mustafa Ozturk Feb 03 '14 at 18:32
The answer is correct. If you look at the source code of the MSVC runtime, you'll see very clearly that memcpy() does no synchronization. Just because Solaris happens to have a thread-safe memcpy() doesn't mean all implementations will, since it is unspecified whether memcpy() is thread-safe or not. Therefore, any programmer worth his salt will assume memcpy() is _not_ thread-safe, and guard it with mutexes. – John Källén Feb 03 '14 at 18:44
2

There's confusion between "thread safe" and "thread safe". You can call memcpy from different threads without problems. However, you can abuse the thread-safe memcpy to create data races, and then all odds are off. And that's apparently what the caller intends to do. – gnasher729 Apr 07 '14 at 12:21

score 6 · Answer 2 · answered Feb 28 '13 at 20:37

6

memcpy is not thread/process safe

answered Feb 28 '13 at 20:37

Drakosha

11,925
4
39
52

Interesting, I would have guessed the contrary. Do you have a reference? – not-a-user Nov 14 '13 at 16:53
By the way, what is "process safe" anyway? I should think it means, that I can call `memcpy` in two different processes at the same time. And that should be trivially true, because different processes actually have their own copy of `memcpy` as much as they have their own copy of any other function. (Or at least the OS guarantees, in case of a shared C library, that the behavior is the same as if each process had its own copy.) – not-a-user Feb 04 '16 at 08:24
Actually the unsafe thing is accessing shared resources, like accessing a file from different processes - but that does not mean that `open`, `read`, and `write` are not process safe. (How would I signal `init` or `explorer.exe` that I'm going to call `write` now, anyway?) – not-a-user Feb 04 '16 at 08:24
@not-a-user: look at the original question and the answers. That will explain what they meant by thread/process safe. You are right about resources, that's indeed the problem :). – Drakosha Feb 04 '16 at 17:46

score 4 · Answer 3 · answered Feb 28 '13 at 21:13

Routines like memcpy() (or memmove()) are part of standard C library, are included through standard <string.h> header and know nothing about any locking mechanics. Locking should be provided by some external way like inter-process mutexes, semaphores or things like this.

score 4 · Answer 4 · edited May 23 '17 at 11:52

You are confusing "atomic" and "thread safe". If you read and write data (with or without memcpy) concurrently in a shared region, that is not safe. But of course copying data itself is thread safe.

memcpy itself is also thread safe, at least on POSIX systems see this one, and therefore I guess it is also on Windows. Anything else would make it quite useless.

If it would be "automatically blocking", it would have to be atomic (or at least manage it's own locks) which would slow down your system. So in your case you should use your own locks.

Is memcpy process-safe?

4 Answers4

Linked