4 ms·

No, it's called testing many concurrent operations. Implementing a complex concurrent algorithm based on your understanding of it, without proper testing is ca

by wubrr 1y ago

No, it's called testing many concurrent operations. Implementing a complex concurrent algorithm based on your understanding of it, without proper testing is called luck, and often called delusion.

JackSlateur 1y ago
What algorithm ? The whole idea is that algorithms are useless, and you should just write a bunch of tests and go with it Yes, if I write stuff with locks, I shall ensure that my code acquires and releases locks correctly This is completely off-topic with the original post; Also, you cannot prove something by tests; Just because you found 100000 cases where your code works does not mean there is not a case where is does not (just as you cannot prove that unicorn does not exist) :)
- sarchertech 1y ago
  > Also, you cannot prove something by tests; Just because you found 100000 cases where your code works does not mean there is not a case where is does not (just as you cannot prove that unicorn does not exist) :) That’s exactly it. For any non trivial program, there exists an infinite number of ways your program can be wrong and still pass all your tests. Unless you can literally test every possible input and every bit of state this holds true.
  - wubrr 1y ago
    For any 'non trivial' program there exists an infinite number of ways your program can be wrong but you still believe it's right. Testing is not a perfect solution to catch all bugs. It's a relatively easy, efficient and reliable way to catch many common bugs though.
    - sarchertech 1y ago
      Sure but it's not a reliable replacement for understanding what the program you wrote is doing either.
  - pfdietz 1y ago
    And yet, (1) testing finds bugs in any nontrivial program that hasn't been tested, and (2) test long enough and with enough variety and you can make programs significantly more reliable. Perfect is the enemy of good, and absent academic fantasies of verified software testing is essential (even then, it's still essential, since you are unlikely to have verified every component of your system.)
    - sarchertech 1y ago
      Sure testing is useful. It's not so useful that you don't need to understand what you're doing though.
- wubrr 1y ago
  It's not about making sure your system is 100% perfect. You cannot do that on any real sufficiently complex system. It's about testing the core functionality in a relatively straightforward and reliable way (including concurrency testing), to catch many common bugs.
  - JackSlateur 1y ago
    My shit is the backbone of a multibillions compagny Common bugs are not enough, uncommon bugs are just too expensive
teraflop 1y ago
You can't easily, automatically test concurrent code for correctness without testing all possible interleavings of instructions, and that state space is usually galactically huge. It is very easy to write multithreaded code that is incorrect (buggy), but where the window of time for the incorrectness to manifest is only a few CPU instructions at a time, sprinkled occasionally throughout the flow of execution. Such a bug is unlikely to be found by test cases in a short period of time, even if you have 1000 concurrent threads running. And yet it'll show up in production eventually if you keep running the code long enough. And of course, when it does show up, you won't be able to reproduce it. That is, I think, what the parent commenter means by "luck". This is similar to the problem you'll run into when testing code that explicitly uses randomness. If you have a program that calls rand(), and it works perfectly almost all the time but fails when rand() returns the specific number 12345678, and you don't know ahead of time to test that value, then your automated test suite is unlikely to ever catch the problem. And testing all possible return values of rand() is usually impractical.
- wubrr 1y ago
  It will obviously not catch all bugs. Nothing will. But it is a relatively easy and reliable way to catch many of them. It works.
- nick__m 1y ago
  There is a cost benefit ratio and context that matters. The repeat the concurent operations 1000times technique is adequate for a CRUD API but it's whofully inadequate for a database engine or garbage collector.
- afiori 1y ago
  and if you have too many threads running you could have slowdowns in the system that prevent the race condition from happening
- nijave 1y ago
  There's still value in eliminating ways your program can wrong even if you can't eliminate all of them. Using your logic, why bother testing at all.

by wubrr 1y ago

No, it's called testing many concurrent operations. Implementing a complex concurrent algorithm based on your understanding of it, without proper testing is called luck, and often called delusion.

JackSlateur 1y ago

What algorithm ? The whole idea is that algorithms are useless, and you should just write a bunch of tests and go with it Yes, if I write stuff with locks, I shall ensure that my code acquires and releases locks correctly This is completely off-topic with the original post; Also, you cannot prove something by tests; Just because you found 100000 cases where your code works does not mean there is not a case where is does not (just as you cannot prove that unicorn does not exist) :)

sarchertech 1y ago
> Also, you cannot prove something by tests; Just because you found 100000 cases where your code works does not mean there is not a case where is does not (just as you cannot prove that unicorn does not exist) :) That’s exactly it. For any non trivial program, there exists an infinite number of ways your program can be wrong and still pass all your tests. Unless you can literally test every possible input and every bit of state this holds true.
- wubrr 1y ago
  For any 'non trivial' program there exists an infinite number of ways your program can be wrong but you still believe it's right. Testing is not a perfect solution to catch all bugs. It's a relatively easy, efficient and reliable way to catch many common bugs though.
  - sarchertech 1y ago
    Sure but it's not a reliable replacement for understanding what the program you wrote is doing either.
- pfdietz 1y ago
  And yet, (1) testing finds bugs in any nontrivial program that hasn't been tested, and (2) test long enough and with enough variety and you can make programs significantly more reliable. Perfect is the enemy of good, and absent academic fantasies of verified software testing is essential (even then, it's still essential, since you are unlikely to have verified every component of your system.)
  - sarchertech 1y ago
    Sure testing is useful. It's not so useful that you don't need to understand what you're doing though.
wubrr 1y ago
It's not about making sure your system is 100% perfect. You cannot do that on any real sufficiently complex system. It's about testing the core functionality in a relatively straightforward and reliable way (including concurrency testing), to catch many common bugs.
- JackSlateur 1y ago
  My shit is the backbone of a multibillions compagny Common bugs are not enough, uncommon bugs are just too expensive

teraflop 1y ago

You can't easily, automatically test concurrent code for correctness without testing all possible interleavings of instructions, and that state space is usually galactically huge. It is very easy to write multithreaded code that is incorrect (buggy), but where the window of time for the incorrectness to manifest is only a few CPU instructions at a time, sprinkled occasionally throughout the flow of execution. Such a bug is unlikely to be found by test cases in a short period of time, even if you have 1000 concurrent threads running. And yet it'll show up in production eventually if you keep running the code long enough. And of course, when it does show up, you won't be able to reproduce it. That is, I think, what the parent commenter means by "luck". This is similar to the problem you'll run into when testing code that explicitly uses randomness. If you have a program that calls rand(), and it works perfectly almost all the time but fails when rand() returns the specific number 12345678, and you don't know ahead of time to test that value, then your automated test suite is unlikely to ever catch the problem. And testing all possible return values of rand() is usually impractical.

wubrr 1y ago
It will obviously not catch all bugs. Nothing will. But it is a relatively easy and reliable way to catch many of them. It works.
nick__m 1y ago
There is a cost benefit ratio and context that matters. The repeat the concurent operations 1000times technique is adequate for a CRUD API but it's whofully inadequate for a database engine or garbage collector.
afiori 1y ago
and if you have too many threads running you could have slowdowns in the system that prevent the race condition from happening
nijave 1y ago
There's still value in eliminating ways your program can wrong even if you can't eliminate all of them. Using your logic, why bother testing at all.