Re: Futexes ain't fast

On 9/26/2024 9:30 AM, Bonita Montero wrote:

Am 30.08.2024 um 22:04 schrieb Chris M. Thomasson:

On 8/30/2024 1:03 PM, Bonita Montero wrote:

Am 30.08.2024 um 21:43 schrieb Chris M. Thomasson:

On 8/30/2024 8:41 AM, Bonita Montero wrote:

Am 30.08.2024 um 15:31 schrieb jseigh:
>

They don't have to be fast, they just have to allow correct synchronization
and allow performant fast paths. ...

>
Futexes are there to make the slow past faster.
The fast path has been fast before.
>

>
No. You are wrong here.

>
>
No, you don't need a futex for the slow path.
>

>
I don't know what you even mean here. Tell me the difference between a slow path and a fast path.

  The fast path is in userspace, the slow path is in kernel space.
 

Basically right. Think of hitting a slow path (before resorting to the kernel), then trying to spin a couple of times in user space before we have to hit a kernel call. Akin to a adaptive mutex. If we can avoid a kernel call, well, go ahead and try a couple of times...
Actually, there is a "method" to do this even with a simple mutex via try_lock. I wrote about it in the past. Hummm... Think of trying to give a little back off with actual work before we resort to waiting in the kernel. Iirc, the pattern was something like, wrt mutex:
<pseudo-code>
Keep in mind that the prefix try_* means try to no other work. Not block! This is important...
________________________
void lock()
{
     while (! try_lock())
     {
         if (! try_to_do_some_other_useful_work())
         {
        lock(); // oh shit, commit to a lock.
             break;
         }
     }
}
________________________
Notice what's occurring here? We can use "other work" as a sort of "natural backoff" in the contended case of a mutex in general... In a certain sense... Instead of spinning, we are doing "actual work" if we can and only if its available. This can work pretty good on certain scenarios wrt how a program is structured...