From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-05-15 17:48:53
On 5/15/21 8:25 PM, AndrÃ© Almeida wrote:
> Ãs 15:05 de 14/05/21, Andrey Semashev via Boost escreveu:
>> On 5/14/21 7:35 PM, AndrÃ© Almeida wrote:
>>> Ãs 18:07 de 13/05/21, Andrey Semashev via Boost escreveu:
>>>> As for use cases outside Boost, that application that I described in the
>>>> LKML post would benefit not only from 64-bit futexes but also from the
>>>> ability to wait on multiple futexes.
>>>> I can provide more details on this use case, if you're
>>> Please, I would love to hear more about that.
>> Well, I've already described most of it in the LKML post and my previous
>> reply. To recap:
>> - The futexes are created in shared memory and accessed by multiple
>> - The futexes are created in threes, one is used as a mutex and the
>> other two as condition variables. We use FUTEX_REQUEUE to move blocked
>> threads from cond vars to the mutex to wake them up upon releasing the
>> - The mutex futex value is divided into sets of bits. Some bits are used
>> for ABA counter and some - for PID of the owner to implement robust
>> semantics. This is where a larger futex would be useful, as the 32-bit
>> putex is not large enough to accommodate a full PID.
>> - For cond var futexes, we're using the futex bitset feature to
>> selectively wake up threads subscribed to different events. In
>> particular, this allows a thread to wake up all other threads within the
>> same process but not the threads from other processes, which is useful
>> for indicating process-local events (e.g. a request for termination).
> Right, so you have a nice custom sync mechanism implementation. If isn't
> confidential, can you explain which kind of application/work load are
> you dealing with? e.g. it's a database
The application is a media processing engine. The synchronization
mechanism I described is a part of the communication mechanism used to
exchange media content between media processing nodes. The application
is scalable and flexible, and the effectiveness of this synchronization
mechanism plays key role in the application performance.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk