Rethinking the futex API - why change the type that uaddr points to? [LWN.net]

Rethinking the futex API - why change the type that uaddr points to?

Posted Jun 23, 2020 13:02 UTC (Tue) by corbet (editor, #1)
In reply to: Rethinking the futex API - why change the type that uaddr points to? by pr1268
Parent article: Rethinking the futex API

I would guess that it has to do with the desire to support different sizes of futexes. Once that's in place, the type of that pointer will vary, so it pretty much has to be void *.

to post comments

Rethinking the futex API - why change the type that uaddr points to?

Posted Jun 23, 2020 17:46 UTC (Tue) by itsmycpu (guest, #139639) [Link]

> I would guess that it has to do with the desire to support different sizes of futexes. Once that's in place, the type of that pointer will vary, so it pretty much has to be void *.

Is it worth the effort and cost of a larger kernel API, though? An application level feature can easily use another atomic variable (which it might like to do anyway), it doesn't have to use the futex value itself, except on the slow path. Not every convenience requires its own kernel API.

The use of futexes requires specialized understanding *and* experience, and application writers are usually better off using higher level library functions like semaphores and mutexes. Leave the support of multiple sizes to the libraries. Or add a Linux-specific C library directly supported by the kernel developers (which can then perhaps also be used by the kernel to communicate with user space processes).

My suggestion is to (first) add a kernel API that can actually make a performance difference: a WAKE-multiple-futexes-with-one-call API. ("Wake" not "wait"). Should be easy to implement (for a kernel developer) and not interfere with the existing functionality and concepts.