Atomic integers & memcpy()

Sorry for being too lazy to go check glibc sources, but does anybody know about memcpy() impementation on Linux glibc? I mean the following (i'm talking about 32-bit systems): integer assignments and readings are atomic operations, but what happens if I memcpy() integer (4 bytes)? Does memcpy() detect platform and optimizes itself so that it will do it in one pass (atomic) or will it do it byte by byte, and thus not being atomic?

EDIT: I mean, atomic integer read and atomic integer write (doesn't matter if context switch happens between read and write (in my case) but it does if it happens on writting half of integer.

If you're relying on behaviour which you need to check the source code for, then you're doing something wrong.

If it really is an integer (on an integer boundary in memory), then use a pointer to an int, and guarantee int read and int write.

The memcpy that comes with glibc is optimized. But it is by far not guaranteed to copy exactly one integer at a time at all times. It is also frequently inlined (as an intrinsic) by the compiler, so it is not even a call to the source of memcpy in the first place.

If you want guarantees that the copy is made one integer at a time, then you'd better write your own function, as Salem says. Otherwise, it may break when the next version of glibc comes out, or if you use a different version of the compiler, a change in compiler settings, or even a change in the code that makes the compiler use a different variant of memcpy implementation [because it judges which version to use based on various heuristics, and one of those could perhaps be the complexity of the code or available registers, so it may decide when you add another variable to the function that it's better to use the call method than the inline intrinsic method].

--
Mats

Thanks for the info. I have this ugly struct of integers shared by few threads, and I don't want to use mutex lock on it (or other type of lock), and I already have function to copy it int by int. But i expected that memcpy() will have this optimization so just asked to be sure.
Thanks again.
Will go along the edge and use it ;)

Quote:

---

Originally Posted by rasta_freak

I don't want to use mutex lock on it (or other type of lock)

---

Why not? Sounds like a classic case for a mutex to me...

QuantumPete

Quote:

---

Originally Posted by QuantumPete

Why not? Sounds like a classic case for a mutex to me...

QuantumPete

---

I already have them enough, and now it's time for some optimization - dump any lock/unlock possible ;)

Why so many locks?

It's not some "thread-happy" solution is it, where each thread continually checks with it's siblings for permission to do things.

If you've got this kind of fine-grained "micro management", then you've got other problems!

Quote:

---

Originally Posted by Salem

Why so many locks?

It's not some "thread-happy" solution is it, where each thread continually checks with it's siblings for permission to do things.

If you've got this kind of fine-grained "micro management", then you've got other problems!

---

I didn't say i have them "many". I have them "just enough" (4 locks vs 6 threads), and blocking now occurs really seldom. And when it occurs, it's because it's allowed there and without any impact on other stuff - it's "expected block". I'm not saying there aren't any bugs, but for now, every lock/unlock/block is profiled and working as expected...
(EDIT: 2 out of that 4 locks are purely graphic-library related and mandatory is my usage case)

Trying to copy data one-by-one, although in an atomic fashion may just be slower than a lock, memcpy, unlock. Don't count on it being faster. Profile the code first.
Just a tip.

Quote:

---

Originally Posted by Elysia

Trying to copy data one-by-one, although in an atomic fashion may just be slower than a lock, memcpy, unlock. Don't count on it being faster. Profile the code first.
Just a tip.

---

Now i just do memcpy() :D

> and blocking now occurs really seldom.
OK, so now it's time to stop optimising then :)

Quote:

---

Originally Posted by Salem

> and blocking now occurs really seldom.
OK, so now it's time to stop optimising then :)

---

Well, problem is a bit "deeper". I'm using allegro 4.3.1 (unaccelerated, thread-unsafe library), and doing some intensive scrolling (it's jukebox system), so every block was, let's say, visible ;) I rearranged code so drawing only blocks on "draw lock", not on my data/state access. It's much better now, but only true solution would be to switch to OpenGL - but that may happen in few months, not sooner (I have to finish this initial version first, then go learn it).