Date: Sun, 28 May 2023 11:26:14 -0400
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.
>
>>> 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.
>
> 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.
Is that what "recursive mutexes" are all about?
> 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.
>
>>> 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.
>
> 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.
Is that what "recursive mutexes" are all about?
-- 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:26:15