Date: Wed, 31 May 2023 21:20:04 -0700
On Wednesday, 31 May 2023 20:46:37 PDT Phil Bouchard wrote:
> > How? It's no different than using a mutex, because it is using a mutex. So
> > if it is not different, how is it better?
>
> Because it is abstracted thus done implicitly.
And yet there's still a lock and the user must know that it is there. The
normal code one would write
if (!container.empty())
container.push)back(1);
is not safe. Is the code above meant to fail t compile? If so, how do you
propose that happen? If not, how do you propose we change our teaching methods
of thread-safe code so that developers will know this, instead of knowing the
regular mutex API?
And this of course becomes more complex when you have two or more containers.
Here's the first part of an algorithm: given containers C1 and C2, if the first
element in C1 isn't in C2, then remove it from there (pop_front) and append
(push_bacl) to C2.
If you realise what the second part will be, feel free to comment on it and
explain how your API will ensure the user writes the proper code for that.
> > How? It's no different than using a mutex, because it is using a mutex. So
> > if it is not different, how is it better?
>
> Because it is abstracted thus done implicitly.
And yet there's still a lock and the user must know that it is there. The
normal code one would write
if (!container.empty())
container.push)back(1);
is not safe. Is the code above meant to fail t compile? If so, how do you
propose that happen? If not, how do you propose we change our teaching methods
of thread-safe code so that developers will know this, instead of knowing the
regular mutex API?
And this of course becomes more complex when you have two or more containers.
Here's the first part of an algorithm: given containers C1 and C2, if the first
element in C1 isn't in C2, then remove it from there (pop_front) and append
(push_bacl) to C2.
If you realise what the second part will be, feel free to comment on it and
explain how your API will ensure the user writes the proper code for that.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-06-01 04:20:08