Thread: Atomic integers & memcpy()

  1. #1
    Registered User
    Join Date
    Jul 2008
    Posts
    133

    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.
    Last edited by rasta_freak; 08-04-2008 at 09:31 PM.

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    Registered User
    Join Date
    Jul 2008
    Posts
    133
    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

  5. #5
    Technical Lead QuantumPete's Avatar
    Join Date
    Aug 2007
    Location
    London, UK
    Posts
    894
    Quote Originally Posted by rasta_freak View Post
    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
    "No-one else has reported this problem, you're either crazy or a liar" - Dogbert Technical Support
    "Have you tried turning it off and on again?" - The IT Crowd

  6. #6
    Registered User
    Join Date
    Jul 2008
    Posts
    133
    Quote Originally Posted by QuantumPete View Post
    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

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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!
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  8. #8
    Registered User
    Join Date
    Jul 2008
    Posts
    133
    Quote Originally Posted by Salem View Post
    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)
    Last edited by rasta_freak; 08-05-2008 at 10:49 AM.

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Last edited by Elysia; 08-05-2008 at 11:05 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Registered User
    Join Date
    Jul 2008
    Posts
    133
    Quote Originally Posted by Elysia View Post
    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()

  11. #11
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > and blocking now occurs really seldom.
    OK, so now it's time to stop optimising then
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  12. #12
    Registered User
    Join Date
    Jul 2008
    Posts
    133
    Quote Originally Posted by Salem View Post
    > 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).

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Link List math
    By t014y in forum C Programming
    Replies: 17
    Last Post: 02-20-2009, 06:55 PM
  2. Replies: 14
    Last Post: 06-28-2006, 01:58 AM
  3. Memcpy(); Errors...
    By Shamino in forum C++ Programming
    Replies: 4
    Last Post: 03-24-2006, 11:35 AM
  4. memcpy with 128 bit registers
    By grady in forum Linux Programming
    Replies: 2
    Last Post: 01-19-2004, 06:25 AM
  5. Replies: 6
    Last Post: 08-04-2003, 10:57 AM