5 ms·

> The GIL might prevent two Python threads executing simultaneously, but it doesn’t change the fact that a Python thread can be preempted, meaning your global s

> The GIL might prevent two Python threads executing simultaneously, but it doesn’t change the fact that a Python thread can be preempted, meaning your global state can change at any point during execution without warning. That thread behavior is enough to reduce the likelihood of races and collisions; particularly if the critical sections are narrow.

laserlight 5y ago
I wouldn’t call it thread-safe when race conditions are possible.
- jldugger 5y ago
  Then we need a term for when code race conditions are possible but rare enough that nobody using the software notices. thread-timebomb?
  - phkahler 5y ago
    >> then we need a term for when code race conditions are possible but rare enough There is no such thing as "rare enough". Random or probabilistic bugs are one of the worst things software can have.
    - lazide 5y ago
      While I agree - plenty of CIOs and managers vote the opposite with their wallets. Why not just set it to auto reboot every week, that seems to fix it - right?
      - phkahler 5y ago
        MCAS only made the planes crash sometimes and then only when a sensor failed
  - nuerow 5y ago
    > Then we need a term for when code race conditions are possible but rare enough that nobody using the software notices. thread-timebomb? There's already a term for that: not thread-safe. The definition of thread safety does not include theoretical or practical assessments regarding how frequent a problem can occurr. It only assesses whether a specific class of problems is eliminated or not.
    - jldugger 5y ago
      >The definition of thread safety does not include theoretical or practical assessments regarding how frequent a problem can occur. Well, obviously. The challenge I am putting forth on HN is to meaningfully describe _usable_ thread-unsafe software. If you've spent enough time outside university, you'll be aware that there are all kinds of theoretical race conditions that are not triggered in practical use.
      - klyrs 5y ago
        If you've worked at industrial scale, you'll be aware that even the most theoretical-seeming race condition will be triggered frequently.
        jldugger 5y ago
        > If you've worked at industrial scale, Fun fact, I actually do! It's from that perspective I wrote that: every time you perturb the software environment, a new set of bugs that didn't happen in the old env before arises.
        The_Colonel 5y ago
        That reminds me how I was called to fix some Java service, which was successfully in production for 10 years with hardly any incident, but it suddenly started crashing hard, all the time. It was of course a thread safety issue (concurrent non-synchronized access to hashmap) which laid dormant for 10 years only to wreak havoc later. Nothing obvious changed (it was still running a decade old JRE), perhaps it was a kernel security patch, perhaps a RAM was replaced or even just the runtime data increased/changed in some way which woke up this monster.
  - formerly_proven 5y ago
    Heisenbug.
  - dkersten 5y ago
    That's not useful. If you have a race condition, you will eventually hit it and when you do, you may get incorrect results or corrupt data. Thread unsafe is thread unsafe, regardless how rare it appears to be. Also, rare on one computer (or today's computer) might not be rare on another (tomorrows faster one for example). These types of bugs are also very hard to detect. You might not know your data is corrupted. Reminds me of how bad calculations in excel has cost companies billions of dollars, except now, the calculations could be "correct" and the error sitting dormant, just waiting for the right timings to happen. Much better to not make assumptions about the safety and think about it up front: if you are using multiple threads, you need to carefully consider your thread safety.
Brian_K_White 5y ago
There is no such thing as "likely". A thing is either possible or not possible.
- kingofpandora 5y ago
  Likelihood refers to probability not possibility.
  - Brian_K_White 5y ago
    There is no such thing as probability. All there is is possible and not possible. I don't know how the point of the comment could be missed, but what I am saying is, it is a mistake, a rookie baby not-a-programmer not even any kind of engineer in any field, to even think in those sorts of terms at all. At least not in the platonic ideal worlds of math or code or protocol or systems design or legal documents, etc. Physical events have probability that is unavoidable. How fast does the gas burn? "Probably this fast" There is no excuse for any coder to even utter the word "likely". The ONLY answers to "Is this operation atomic?" or "Is this function correct?" or "Does this cpu perform division correctly?" Is either yes or no. There is no freaking "Most of the time." "Likely" only exists in the realm of user data and where it is explicitly created as part of an algorythm.
    - yholio 5y ago
      There are whole branches of computer science and IT dedicated to reducing the likelihood of unpleasant outcomes: cryptography, security, disaster recovery etc. You cannot guarantee your public key algorithm is impossible to break, but you can use keys long enough that an attacker has an arbitrarily low chance of succes with the best known methods. You cannot prove your program is bug free, outside of highly specialized fields like aircraft control, but you can build a multi-layered architecture that can reduce the likelihood of successful intrusion. You cannot prevent a EMP bomb from wiping all your hard-drives at once, but you will likely maintain integrity of your database for uncorrelated hardware errors. "Likely" is a tool that works in the real world. If you will chase mathematic certainty, your competition will likely eat your lunch. Where you might be correct is that "unlikely" is very close to "likely" in the particular topic of thread safety, you just need a sufficiently large userbase with workloads and environments sufficiently different from your test setup.
avianlyric 5y ago
That just means the GIL is good at hiding concurrency bugs. It doesn’t make writing correct code any easier. Arguably you could say it makes writing correct concurrent code harder, because it’ll take significantly longer for concurrency bugs cause errors.

laserlight 5y ago

I wouldn’t call it thread-safe when race conditions are possible.

jldugger 5y ago
Then we need a term for when code race conditions are possible but rare enough that nobody using the software notices. thread-timebomb?
- phkahler 5y ago
  >> then we need a term for when code race conditions are possible but rare enough There is no such thing as "rare enough". Random or probabilistic bugs are one of the worst things software can have.
  - lazide 5y ago
    While I agree - plenty of CIOs and managers vote the opposite with their wallets. Why not just set it to auto reboot every week, that seems to fix it - right?
    - phkahler 5y ago
      MCAS only made the planes crash sometimes and then only when a sensor failed
- nuerow 5y ago
  > Then we need a term for when code race conditions are possible but rare enough that nobody using the software notices. thread-timebomb? There's already a term for that: not thread-safe. The definition of thread safety does not include theoretical or practical assessments regarding how frequent a problem can occurr. It only assesses whether a specific class of problems is eliminated or not.
  - jldugger 5y ago
    >The definition of thread safety does not include theoretical or practical assessments regarding how frequent a problem can occur. Well, obviously. The challenge I am putting forth on HN is to meaningfully describe _usable_ thread-unsafe software. If you've spent enough time outside university, you'll be aware that there are all kinds of theoretical race conditions that are not triggered in practical use.
    - klyrs 5y ago
      If you've worked at industrial scale, you'll be aware that even the most theoretical-seeming race condition will be triggered frequently.
      - jldugger 5y ago
        > If you've worked at industrial scale, Fun fact, I actually do! It's from that perspective I wrote that: every time you perturb the software environment, a new set of bugs that didn't happen in the old env before arises.
      - The_Colonel 5y ago
        That reminds me how I was called to fix some Java service, which was successfully in production for 10 years with hardly any incident, but it suddenly started crashing hard, all the time. It was of course a thread safety issue (concurrent non-synchronized access to hashmap) which laid dormant for 10 years only to wreak havoc later. Nothing obvious changed (it was still running a decade old JRE), perhaps it was a kernel security patch, perhaps a RAM was replaced or even just the runtime data increased/changed in some way which woke up this monster.
- formerly_proven 5y ago
  Heisenbug.
- dkersten 5y ago
  That's not useful. If you have a race condition, you will eventually hit it and when you do, you may get incorrect results or corrupt data. Thread unsafe is thread unsafe, regardless how rare it appears to be. Also, rare on one computer (or today's computer) might not be rare on another (tomorrows faster one for example). These types of bugs are also very hard to detect. You might not know your data is corrupted. Reminds me of how bad calculations in excel has cost companies billions of dollars, except now, the calculations could be "correct" and the error sitting dormant, just waiting for the right timings to happen. Much better to not make assumptions about the safety and think about it up front: if you are using multiple threads, you need to carefully consider your thread safety.

Brian_K_White 5y ago

There is no such thing as "likely". A thing is either possible or not possible.

kingofpandora 5y ago
Likelihood refers to probability not possibility.
- Brian_K_White 5y ago
  There is no such thing as probability. All there is is possible and not possible. I don't know how the point of the comment could be missed, but what I am saying is, it is a mistake, a rookie baby not-a-programmer not even any kind of engineer in any field, to even think in those sorts of terms at all. At least not in the platonic ideal worlds of math or code or protocol or systems design or legal documents, etc. Physical events have probability that is unavoidable. How fast does the gas burn? "Probably this fast" There is no excuse for any coder to even utter the word "likely". The ONLY answers to "Is this operation atomic?" or "Is this function correct?" or "Does this cpu perform division correctly?" Is either yes or no. There is no freaking "Most of the time." "Likely" only exists in the realm of user data and where it is explicitly created as part of an algorythm.
  - yholio 5y ago
    There are whole branches of computer science and IT dedicated to reducing the likelihood of unpleasant outcomes: cryptography, security, disaster recovery etc. You cannot guarantee your public key algorithm is impossible to break, but you can use keys long enough that an attacker has an arbitrarily low chance of succes with the best known methods. You cannot prove your program is bug free, outside of highly specialized fields like aircraft control, but you can build a multi-layered architecture that can reduce the likelihood of successful intrusion. You cannot prevent a EMP bomb from wiping all your hard-drives at once, but you will likely maintain integrity of your database for uncorrelated hardware errors. "Likely" is a tool that works in the real world. If you will chase mathematic certainty, your competition will likely eat your lunch. Where you might be correct is that "unlikely" is very close to "likely" in the particular topic of thread safety, you just need a sufficiently large userbase with workloads and environments sufficiently different from your test setup.

avianlyric 5y ago

That just means the GIL is good at hiding concurrency bugs. It doesn’t make writing correct code any easier. Arguably you could say it makes writing correct concurrent code harder, because it’ll take significantly longer for concurrency bugs cause errors.