twerdster
twerdster

Reputation: 5027

Is memcpy process-safe?

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?

Upvotes: 8

Views: 14743

Answers (4)

not-a-user
not-a-user

Reputation: 4327

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.

Upvotes: 4

Roman Nikitchenko
Roman Nikitchenko

Reputation: 13046

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.

Upvotes: 4

John K&#228;ll&#233;n
John K&#228;ll&#233;n

Reputation: 7943

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);

Upvotes: 12

Drakosha
Drakosha

Reputation: 12165

memcpy is not thread/process safe

Upvotes: 6

Related Questions