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 4:00 UTC (Tue) by pr1268 (guest, #24648)
Parent article: Rethinking the futex API

    int futex(int *uaddr, [...]

And from the proposed patch set mentioned below:

    int futex_wait(void *uaddr, [...]
    int futex_wait_time32(void *uaddr, [...]
    int futex_wake(void *uaddr, [...]

Just curious, and I couldn't find in our editor's article, nor in the comments: why is uaddr being changed from an int * to a void *?

to post comments

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

Posted Jun 23, 2020 13:02 UTC (Tue) by corbet (editor, #1) [Link] (1 responses)

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 *.

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.