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.