C++ Logo


Advanced search

Re: [std-proposals] Fwd: set_new_handler extension

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Sun, 28 May 2023 11:13:59 -0400
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);
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.

Received on 2023-05-28 15:14:13