Thursday, October 7, 2021

Digest for comp.lang.c++@googlegroups.com - 5 updates in 1 topic

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 07 12:21PM -0700

On 10/7/2021 3:15 AM, Bonita Montero wrote:
 
>> You can call access to an unlocked mutex a fast-path.
 
> Yes, but because of that fast path a mutex isn't lock-free.
> You say that everything having a fast path could be called lock-free.
 
I am saying the fast-path is lock/wait-free. Then there is the
slow-path... A completely different story. A futex and eventcount are
used to allow the data-structure to be waited on. A futex is much lower
level than eventcount. An eventcount is kind of akin to a condvar for
lock/wait-free algorithms. A futex can be used to build an eventcount.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 07 12:26PM -0700

On 10/7/2021 3:16 AM, Bonita Montero wrote:
>> for  a fast-path, and use a Futex or Eventcount for the slow-path.
 
> Lock-free algorithms don't have a slow path.
> That's while they don't lock and you've to poll them.
 
Why poll them? Add a slow-path using futex or eventcount... Is seems
that you are having a hard time understanding this... This keeps the
fast-path for periods of load, when sheer performance matters. Under
load, the data-structure is much more likely to hit fast-paths, and reap
the benefits from lock/wait free algorithms. Got it?
Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 07 08:14PM

> used to allow the data-structure to be waited on. A futex is much lower
> level than eventcount. An eventcount is kind of akin to a condvar for
> lock/wait-free algorithms. A futex can be used to build an eventcount.
Well only thing you can do is sleep not to overheat :P
 
--
 
7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...
Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 07 08:16PM

> fast-path for periods of load, when sheer performance matters. Under
> load, the data-structure is much more likely to hit fast-paths, and reap
> the benefits from lock/wait free algorithms. Got it?
Yeah, problem is when you don't have something usefull to do :P
 
 
--
 
7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 07 02:27PM -0700

On 10/7/2021 1:16 PM, Branimir Maksimovic wrote:
>> load, the data-structure is much more likely to hit fast-paths, and reap
>> the benefits from lock/wait free algorithms. Got it?
> Yeah, problem is when you don't have something usefull to do :P
 
Indeed. There is a funny way to use try_lock to try to gain this sort of
pattern... Iirc, it went something like:
__________________________
void lock()
{
while (! try_lock())
{
if (! try_to_do_something_else())
{
lock();
break;
}
}
}
__________________________
 
So, if something else was done, we can try_lock again. Iirc, I even put
a limit on how many times try_lock() can be called. Akin to an adaptive
mutex, except instead of spinning, we see if something else can be done.
 
It does work in certain scenarios and/or setups...
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: