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 interested.
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 processes. - 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 mutex. - 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.