Date: Sun, 28 May 2023 11:18:44 -0400
On 5/28/23 11:13, Jason McKesson via Std-Proposals wrote:
> 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(....)
> }
> ```
All you'd have to do is:
std::lock_guard<std::mutex> lock(container.mutex());
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.
> 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(....)
> }
> ```
All you'd have to do is:
std::lock_guard<std::mutex> lock(container.mutex());
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.
-- Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> Founder & CEO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2023-05-28 15:18:45