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.

> > 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.

A layer of code that cannot fix a problem should not *try* to fix the
problem. As I explained in a different post, it makes the eventual
fixing of the problem that much harder, as whether to lock the mutex
must be determined by whether or not your thread has already locked
it.