On Sun, May 28, 2023 at 11:26 AM Phil Bouchard <boost_at_[hidden]> wrote:
>
>
>
> On 5/28/23 11:19, Jason McKesson via Std-Proposals wrote:
> > On Sun, May 28, 2023 at 11:11 AM Phil Bouchard via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >>
> >>
> >>
> >> On 5/28/23 11:04, Federico Kircheis via Std-Proposals wrote:
> >>> On 28/05/2023 16.55, Phil Bouchard via Std-Proposals wrote:
> >>>> This is pretty much what I had in mind:
> >>>> https://github.com/philippeb8/std__ts/blob/master/ts.h
> >>>>
> >>>> Very cost / beneficial.
> >>>>
> >>>
> >>>
> >>> One of the issues I have with such classes is that they make other tools
> >>> for finding bugs, like sanitizers and valgrind, useless.
> >>
> >> These tools are already 100% useless for GPU code.
> >
> > Are you doing a lot of memory allocation or `std::mutex` calls on a
> > GPU? Because GPU threads don't generally have the same
> > forward-progress guarantees of CPU threads. And without that, `mutex`
> > just isn't going to work.
>
> It's a mixture but as soon as you use GPU then forget about all the
> memory sanitizers.

But you also don't encounter most of the problems that memory
sanitizers exist to solve. So your claim is pointless.

> >>> This code is racy, even with the internal mutex:
> >>>
> >>> if(container.empty()){
> >>> container.insert(....)
> >>> }
> >>>
> >>>
> >>> but since the data is protected by mutexes and synchronized, not tools
> >>> will complain (AFAIK).
> >>>
> >>> Thus even if such class would be standardized, in most cases it is
> >>> useless/it is a not a good primitive for multi-threaded code.
> >>
> >> Well it eliminates all possible crashes from the container layer and all
> >> the dependencies above it. It doesn't fix everything but STL's
> >> accountability at least.
> >
> > A fix for a problem that doesn't fix the problem and makes it really
> > hard for the user to actually fix the problem does not count as a fix
> > for the problem. Believing that every layer needs to provide
> > "accountability" rather than "functionality" is just not how you write
> > good code.
>
> Functionality is the lower level layer but you need to offer ways to
> program at higher level easily without have to reinvent the wheel over
> and over also.

But that's the thing: you're not actually making anything easier on anyone.

Let's make sure we all understand what "the problem" is that we're
trying to solve. There's a container. Sometimes, you share containers
among threads. When you do that, you need to ensure that container
access is appropriately gated so that you don't get race conditions.
Everyone knows this.

The problem is, they forget. Sometimes, they forget to do the access
correctly. Sometimes they change the nature of the access so that it
requires locking. Sometimes someone shared an object and forget to
change all of the other accessors of that object. Or whatever. People
forget.

Your proposed solution is to make the container lock itself. Always.
The problem is this:

It doesn't actually solve the problem.

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.