Date: Thu, 1 Jun 2023 02:22:36 -0400
On Wed, May 31, 2023 at 10:55 PM Phil Bouchard via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On 5/31/23 22:48, Thiago Macieira wrote:
> > On Wednesday, 31 May 2023 19:44:10 PDT Phil Bouchard wrote:
> >>> In other words, we need a std::lock_guard or equivalent. How is this
> >>> different from a regular mutex? This is a very simple example and yet
> >>> we've already got ourselves a mutex and needing to think about which
> >>> operations need to be protected so the state doesn't change from under
> >>> us.
> >>
> >> This example shows what I had in mind:
> >> https://github.com/philippeb8/std__ts/blob/master/ts.cpp
> >
> > You didn't address my point, that this simple solution required a mutex and
> > reasoning what the critical section span should be. How is this any different,
> > let alone safer, from what we already have?
>
> My reasoning is:
> - This brings parallel programming to a higher level of abstraction (the
> definition of intelligence actually);
Nonsense. Parallel programming is already at "a higher level of
abstraction". `promise/future` is already at "a higher level of
abstraction" than `optional` and the like.
Containers that aren't thread-safe are not stopping people from
writing parallel programs. They're not stopping people from building
solid thread-safe abstractions that higher-level code can use.
> - It prevents the whole planet from reinventing the wheel;
If people are constantly reinventing this particular wheel... where
are all the wheels? Why does Boost have 3 different vector types, but
not one of them is "thread-safe"? Asio has a number of thread-safe
data structures, but they're all specific to inter-thread
communication. That is, they're *not* generic containers that happen
to be shared. Poco and Qt come up empty as well. They have thread-safe
tools, but not generic containers that they made thread-safe.
If the only people "reinventing the wheel" are a small cloister of
people who are convinced that this wheel is very important, while the
rest of the world doesn't use those wheels... maybe they're not that
useful.
> - This *removes* race conditions, it can't add any runtime bugs in any way.
At best, it only removes the easiest race conditions to detect. The
harder, more complicated ones, still exist and are still difficult to
track down or fix.
You can claim that this is 90% of the race conditions from containers,
but there's no evidence of this.
<std-proposals_at_[hidden]> wrote:
>
>
>
> On 5/31/23 22:48, Thiago Macieira wrote:
> > On Wednesday, 31 May 2023 19:44:10 PDT Phil Bouchard wrote:
> >>> In other words, we need a std::lock_guard or equivalent. How is this
> >>> different from a regular mutex? This is a very simple example and yet
> >>> we've already got ourselves a mutex and needing to think about which
> >>> operations need to be protected so the state doesn't change from under
> >>> us.
> >>
> >> This example shows what I had in mind:
> >> https://github.com/philippeb8/std__ts/blob/master/ts.cpp
> >
> > You didn't address my point, that this simple solution required a mutex and
> > reasoning what the critical section span should be. How is this any different,
> > let alone safer, from what we already have?
>
> My reasoning is:
> - This brings parallel programming to a higher level of abstraction (the
> definition of intelligence actually);
Nonsense. Parallel programming is already at "a higher level of
abstraction". `promise/future` is already at "a higher level of
abstraction" than `optional` and the like.
Containers that aren't thread-safe are not stopping people from
writing parallel programs. They're not stopping people from building
solid thread-safe abstractions that higher-level code can use.
> - It prevents the whole planet from reinventing the wheel;
If people are constantly reinventing this particular wheel... where
are all the wheels? Why does Boost have 3 different vector types, but
not one of them is "thread-safe"? Asio has a number of thread-safe
data structures, but they're all specific to inter-thread
communication. That is, they're *not* generic containers that happen
to be shared. Poco and Qt come up empty as well. They have thread-safe
tools, but not generic containers that they made thread-safe.
If the only people "reinventing the wheel" are a small cloister of
people who are convinced that this wheel is very important, while the
rest of the world doesn't use those wheels... maybe they're not that
useful.
> - This *removes* race conditions, it can't add any runtime bugs in any way.
At best, it only removes the easiest race conditions to detect. The
harder, more complicated ones, still exist and are still difficult to
track down or fix.
You can claim that this is 90% of the race conditions from containers,
but there's no evidence of this.
Received on 2023-06-01 06:22:48