5 ms·

The answer is: don't guess.

chrisseaton 5y ago
We don't - and in this example we'd combine atomics rather than guess that the user wanted the thread to yield between them, since they never told us that.
- overgard 5y ago
  That's not true, you are making a guess: that the user doesn't care about the intermediate stage. Not guessing would mean generating the code as specified. It doesn't matter if you think its a bad idea, the whole ethos of C is trust the programmer.
  - chrisseaton 5y ago
    > you are making a guess: that the user doesn't care about the intermediate stage That's not a guess - the user didn't put anything in between them so we know they haven't required them to be separate. Keeping them separate would be making the guess - a guess that they need them to be separate. Why should we invent that constraint when the user never wrote it? > Not guessing would mean generating the code as specified. We are generating it as specified - nothing in the specification says atomic actions have to be run independently. Why should I invent extra constraints that don't exist in the specification?
    - overgard 5y ago
      Oh come on, that language lawyering is sophistry. If I write 4 instructions that are "atomic" I expect 4 instructions. If I end up with one, they werent really "atoms" were they? I do not expect what you just said. I may think, gee, perhaps I don't need 4 instructions, but what you are doing is undeniably changing the meaning of the program, even if you think it's close enough. The fact that there's an article about this tends to agree with me that most people think: wtf happened?
      - kllrnohj 5y ago
        If you're going to use atomics, you should be reading what guarantees those atomics actually provide. In this case of memory_order_relaxed they pretty clearly specify they don't provide any cross-thread synchronization. So if you wrote those 4 atomics expecting something the docs explicitly & clearly say it doesn't provide, that's pretty much entirely your fault and not "language lawyering"
      - chrisseaton 5y ago
        > If I write 4 instructions that are "atomic" I expect 4 instructions. Why do you expect that? Nobody ever promised you that. If you expect something you weren’t promised then that’s on you. > If I end up with one, they werent really "atoms" were they? Atomic has a technical definition - it means either applied fully or not at all. That doesn’t preclude combining. > what you are doing is undeniably changing the meaning of the program It doesn’t! According to the spec we’re both working off. If you think the spec is wrong then change it. But I can’t guess what you want unless you tell me using the spec.
        overgard 5y ago
        > Why do you expect that? Because I wrote it? > Nobody ever promised you that. I just assumed that compiler writers had empathy for humans, my bad. > It doesn’t! According to the spec we’re both working off. If you think the spec is wrong then change it. But I can’t guess what you want unless you tell me using the spec. How big is the spec and how many working programmers do you think are super intimately familiar? Do you think this article would be on the front page if this information wasn't surprising? Are you building a compiler for humans, or are you just chasing metrics and getting the smug satisfaction of telling users "I told you so" when shit doesn't work in an intuitive way? If you want to beat me over the head with "the spec says", you win, master language lawyer. I build things for a living and I like it when the code I specify is the code that's generated. You can blame users all you want, but maybe after the trillionth zero day exploit because nobody gets these things right you might consider empathy and developer ergonomics.
        5y ago

We don't - and in this example we'd combine atomics rather than guess that the user wanted the thread to yield between them, since they never told us that.

overgard 5y ago
That's not true, you are making a guess: that the user doesn't care about the intermediate stage. Not guessing would mean generating the code as specified. It doesn't matter if you think its a bad idea, the whole ethos of C is trust the programmer.
- chrisseaton 5y ago
  > you are making a guess: that the user doesn't care about the intermediate stage That's not a guess - the user didn't put anything in between them so we know they haven't required them to be separate. Keeping them separate would be making the guess - a guess that they need them to be separate. Why should we invent that constraint when the user never wrote it? > Not guessing would mean generating the code as specified. We are generating it as specified - nothing in the specification says atomic actions have to be run independently. Why should I invent extra constraints that don't exist in the specification?
  - overgard 5y ago
    Oh come on, that language lawyering is sophistry. If I write 4 instructions that are "atomic" I expect 4 instructions. If I end up with one, they werent really "atoms" were they? I do not expect what you just said. I may think, gee, perhaps I don't need 4 instructions, but what you are doing is undeniably changing the meaning of the program, even if you think it's close enough. The fact that there's an article about this tends to agree with me that most people think: wtf happened?
    - kllrnohj 5y ago
      If you're going to use atomics, you should be reading what guarantees those atomics actually provide. In this case of memory_order_relaxed they pretty clearly specify they don't provide any cross-thread synchronization. So if you wrote those 4 atomics expecting something the docs explicitly & clearly say it doesn't provide, that's pretty much entirely your fault and not "language lawyering"
    - chrisseaton 5y ago
      > If I write 4 instructions that are "atomic" I expect 4 instructions. Why do you expect that? Nobody ever promised you that. If you expect something you weren’t promised then that’s on you. > If I end up with one, they werent really "atoms" were they? Atomic has a technical definition - it means either applied fully or not at all. That doesn’t preclude combining. > what you are doing is undeniably changing the meaning of the program It doesn’t! According to the spec we’re both working off. If you think the spec is wrong then change it. But I can’t guess what you want unless you tell me using the spec.
      - overgard 5y ago
        > Why do you expect that? Because I wrote it? > Nobody ever promised you that. I just assumed that compiler writers had empathy for humans, my bad. > It doesn’t! According to the spec we’re both working off. If you think the spec is wrong then change it. But I can’t guess what you want unless you tell me using the spec. How big is the spec and how many working programmers do you think are super intimately familiar? Do you think this article would be on the front page if this information wasn't surprising? Are you building a compiler for humans, or are you just chasing metrics and getting the smug satisfaction of telling users "I told you so" when shit doesn't work in an intuitive way? If you want to beat me over the head with "the spec says", you win, master language lawyer. I build things for a living and I like it when the code I specify is the code that's generated. You can blame users all you want, but maybe after the trillionth zero day exploit because nobody gets these things right you might consider empathy and developer ergonomics.
        5y ago