Search:

Type: Posts; User: King Mir

Search: Search took 0.02 seconds.

  1. Replies
    16
    Views
    4,945

    Atomic do impose an odering. f() is sequenced...

    Atomic do impose an odering.

    f() is sequenced before g(). If g() preforms an release on an atomic 'gatom', then it synchronizes with a future thread that does an aquire on 'gatom'. Then in that...
  2. Replies
    16
    Views
    4,945

    It has to either assume that any unresolvable...

    It has to either assume that any unresolvable function modifies an atomic, and therefore not reorder, or reorder when linking. Also, the CPU can reorder. Additionally, The C standard does not require...
  3. Replies
    16
    Views
    4,945

    I agree with all of what you said except this...

    I agree with all of what you said except this nitpick: That quote 's correct, as long as the order of IO and threading primatives is the same.

    But you can and must reason about the order of access...
  4. Replies
    16
    Views
    4,945

    Atomics and mutexes do change things, because an...

    Atomics and mutexes do change things, because an implementation (compiler or CPU) is not expected to guarantee that ordering optimisations don't change observable effects when accessing memory...
  5. Replies
    16
    Views
    4,945

    For IO that's saying the same thing in a...

    For IO that's saying the same thing in a different way. For C11 concurrency though, trying to define the guarantees provided my atomics and mutexes as an "effect" seems awkward at best. I suppose...
  6. Replies
    16
    Views
    4,945

    Also, even in grumpy's code, the order of...

    Also, even in grumpy's code, the order of evaluation may not be fixed if f(), g(), and h() do not do IO, access atomics, mutexes, or volitile variables, or access the same memory location. Basically...
Results 1 to 6 of 6