On Sun, May 28, 2023 at 11:04 AM Federico Kircheis via Std-Proposals
<std-proposals_at_[hidden]> 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.
>
> 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.

What's worse is that "fixing it" is really hard. You'd have to do
something like this

```
container_lock c(container);
if(container.empty())
{
  container.insert(....)
}
```
Where `container_lock` is some kind of type that is able to lock the
mutex *and* communicate to the container that it has locked the mutex,
so the container shouldn't lock it. But that flag is conceptually
thread-local; it *must only* be checked by calls into the container
from the thread that did a `container_lock`. All other threads must
lock the mutex.

So basically instead of a flag, it needs to be a thread ID. And I'm
not even sure this doesn't constitute a race condition of some sort.