I don't understand, by "standard mechanism" do you mean std::lock_guard?
LockRef uses that, see line 17 of the code.
https://godbolt.org/z/6klEJn
On Fri, Mar 22, 2019 at 1:10 PM Alan Carroll
wrote:
> >
> > Yes, but I think that advantage of using a standard mechanism will be
> more
> > acceptab
>
> Yes, but I think that advantage of using a standard mechanism will be more
> acceptable than a distinctly different mechanism. Better to take advantage
> of existing habits.
>
>
I don't understand. Part of the point is that you only have a reference to
the data (aPoint in this case) while it is also locked.
On Fri, Mar 22, 2019 at 10:16 AM Alan Carroll
wrote:
> I'd be more tempted to specialize `std::lock_guard` for the class. E.g. so
> that
>
> std::lock_guard lock{aP
I'd be more tempted to specialize `std::lock_guard` for the class. E.g. so
that
std::lock_guard lock{aPoint};
works an RAII lock on `aPoint`. I think that makes it easier because
there's only one thing the user has to remember, "lock_guard".
On Fri, Mar 22, 2019 at 9:19 AM Walt Karas
wrote:
>
scoped_lock is I think an alternative to lock_guard to avoid deadlock when
multiple mutexes must be locked at the same time.
The point of the utility I propose is a fail-safe to make sure that
mutex-protected data is not accessed without locking the mutex, and clarity
about what data the mutex is
I was thinking of https://en.cppreference.com/w/cpp/thread/scoped_lock
Jason
On Thu, Mar 21, 2019 at 4:53 PM Walt Karas
wrote:
> What's the name of it in the Standard Lib?
>
> On Thu, Mar 21, 2019 at 4:45 PM Jason Kenny .invalid>
> wrote:
>
> > I am unclear why it is needed. C++ 17 already has
What's the name of it in the Standard Lib?
On Thu, Mar 21, 2019 at 4:45 PM Jason Kenny
wrote:
> I am unclear why it is needed. C++ 17 already has this in the std library.
> these should be used instead of making our own
>
> Jason
>
> On Wed, Mar 20, 2019 at 4:17 PM Leif Hedstrom wrote:
>
> > Do
I am unclear why it is needed. C++ 17 already has this in the std library.
these should be used instead of making our own
Jason
On Wed, Mar 20, 2019 at 4:17 PM Leif Hedstrom wrote:
> Don’t we have scoped mutexes already ?
>
> — Leif
>
> > On Mar 20, 2019, at 12:08, Walt Karas
> wrote:
> >
> >
The ATS code uses that terminology. The C++ Standard lib has
std::lock_guard . If you are saying we should not transition to the stdlib
stuff, why?
The utility I'm proposing makes it a little more convenient to use a mutex
with lock_guards in typical cases that a mutex is used. It also makes it
Don’t we have scoped mutexes already ?
— Leif
> On Mar 20, 2019, at 12:08, Walt Karas wrote:
>
> https://godbolt.org/z/6klEJn
>
> Useful for mutex-protected objects, where the mutex is only locked within
> code blocks. Could be used in this PR:
>
> https://github.com/apache/trafficserver/pu
https://godbolt.org/z/6klEJn
Useful for mutex-protected objects, where the mutex is only locked within
code blocks. Could be used in this PR:
https://github.com/apache/trafficserver/pull/5187
11 matches
Mail list logo
