Date: Sun, 28 May 2023 15:00:14 -0400
On 5/28/23 14:33, Jason McKesson via Std-Proposals wrote:
> On Sun, May 28, 2023 at 12:19 PM Phil Bouchard <boost_at_[hidden]> wrote:
>>
>>
>>
>> On 5/28/23 12:08, Jason McKesson via Std-Proposals wrote:
>>
>>> Remember: the problem is that users *forget*. But your solution
>>> doesn't make it impossible to forget. There are many circumstances
>>> where common access patterns *require* the user to take special action
>>> in order to avoid data races. Because this requires manual
>>> intervention, users must identify these scenarios and *remember* to
>>> take that intervention.
>>>
>>> Therefore, people can still forget to do this. And therefore, all the
>>> bugs are still there.
>>>
>>> Your proposed solution provides only the illusion of safety, not
>>> actual safety. A solution that works only 60% of the time without
>>> *correct* manual intervention is, for most users, no better than a
>>> solution that works 0% of the time. It still requires the user to be
>>> mindful of their interactions with the container, to be heavily aware
>>> that the container is shared and to treat it specially. One code
>>> change can still turn previously functional code into broken code.
>>>
>>> So your solution is not only inefficient, it is ineffective.
>>
>> Well first I would increase the 60% up to 90%.
>
> What's your basis for that "90%" guess? I have no data to back up
> "60%", but I could believe a number as low as 30% depending on what
> the code is doing with the container. The thing you're not getting is
> that these kinds of issues crop up in a myriad of ways. Something as
> simple as:
>
> ```
> container.push_back(20);
> container.push_back(40);
> ```
>
> May need a lock.
>
> And what's worse is... it may *not*. You cannot know, by inspection,
> if this code is doing the intended thing or not. This can only be
> determined by examining the context surrounding it.
>
> The best advice I was ever given about thread-safe code boils down to
> this: if your "thread-safe code" is not obviously, *proveably*
> thread-safe, then it isn't thread-safe code.
>
> The fact that we do not know if the above code is wrong means that it
> *is wrong*. And "solutions" to "thread-safety" that do not always
> force you to write correct code... are not solutions to thread safety.
>
>> If 90% is insufficient for you and 0% is your preference then that is
>> your personal choice, no everybody else's.
>
> Even if we were to believe your 90% number, that's still 10% of every
> interaction with any container that's broken. That makes debugging
> *harder*, not easier. The problem will manifest itself less often, and
> thus you are more likely to ship broken code to users.
>
> And then misplace the blame on other code due to being told that the
> container you're using is "thread safe" and therefore the bug you
> wrote is actually someone else's problem.
>
> Put a different way, 90% of a cat is not 90% as good as a whole cat.
> It's a bloody, Godawful mess. The problem with "mostly" solutions is
> that "sometimes" happens way too often to just pretend that it
> doesn't.
>
> There's a reason why five-9s reliability requires *five* 9s.
Yes you're right about the 100%. It's just like astrophysics, either
you're fully 100% right otherwise no one will use your 90% right theory.
That's with C++ Superset will fix possible thread-unsafe crashes and
conditional expressions. The rest will be up to the programmer.
But all military systems cannot afford crashes, so they use static
memory but it's still not fully bulletproof. So the C++ Superset
solution is already better to a certain degree, now what you just
mentioned are purely at the algorithmic level, and are not possible
thread-unsafe crashes.
> On Sun, May 28, 2023 at 12:19 PM Phil Bouchard <boost_at_[hidden]> wrote:
>>
>>
>>
>> On 5/28/23 12:08, Jason McKesson via Std-Proposals wrote:
>>
>>> Remember: the problem is that users *forget*. But your solution
>>> doesn't make it impossible to forget. There are many circumstances
>>> where common access patterns *require* the user to take special action
>>> in order to avoid data races. Because this requires manual
>>> intervention, users must identify these scenarios and *remember* to
>>> take that intervention.
>>>
>>> Therefore, people can still forget to do this. And therefore, all the
>>> bugs are still there.
>>>
>>> Your proposed solution provides only the illusion of safety, not
>>> actual safety. A solution that works only 60% of the time without
>>> *correct* manual intervention is, for most users, no better than a
>>> solution that works 0% of the time. It still requires the user to be
>>> mindful of their interactions with the container, to be heavily aware
>>> that the container is shared and to treat it specially. One code
>>> change can still turn previously functional code into broken code.
>>>
>>> So your solution is not only inefficient, it is ineffective.
>>
>> Well first I would increase the 60% up to 90%.
>
> What's your basis for that "90%" guess? I have no data to back up
> "60%", but I could believe a number as low as 30% depending on what
> the code is doing with the container. The thing you're not getting is
> that these kinds of issues crop up in a myriad of ways. Something as
> simple as:
>
> ```
> container.push_back(20);
> container.push_back(40);
> ```
>
> May need a lock.
>
> And what's worse is... it may *not*. You cannot know, by inspection,
> if this code is doing the intended thing or not. This can only be
> determined by examining the context surrounding it.
>
> The best advice I was ever given about thread-safe code boils down to
> this: if your "thread-safe code" is not obviously, *proveably*
> thread-safe, then it isn't thread-safe code.
>
> The fact that we do not know if the above code is wrong means that it
> *is wrong*. And "solutions" to "thread-safety" that do not always
> force you to write correct code... are not solutions to thread safety.
>
>> If 90% is insufficient for you and 0% is your preference then that is
>> your personal choice, no everybody else's.
>
> Even if we were to believe your 90% number, that's still 10% of every
> interaction with any container that's broken. That makes debugging
> *harder*, not easier. The problem will manifest itself less often, and
> thus you are more likely to ship broken code to users.
>
> And then misplace the blame on other code due to being told that the
> container you're using is "thread safe" and therefore the bug you
> wrote is actually someone else's problem.
>
> Put a different way, 90% of a cat is not 90% as good as a whole cat.
> It's a bloody, Godawful mess. The problem with "mostly" solutions is
> that "sometimes" happens way too often to just pretend that it
> doesn't.
>
> There's a reason why five-9s reliability requires *five* 9s.
Yes you're right about the 100%. It's just like astrophysics, either
you're fully 100% right otherwise no one will use your 90% right theory.
That's with C++ Superset will fix possible thread-unsafe crashes and
conditional expressions. The rest will be up to the programmer.
But all military systems cannot afford crashes, so they use static
memory but it's still not fully bulletproof. So the C++ Superset
solution is already better to a certain degree, now what you just
mentioned are purely at the algorithmic level, and are not possible
thread-unsafe crashes.
-- Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> Founder & CEO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2023-05-28 19:00:16