Add support for setting priority ceiling and/or priority inheritance on std::mutex

[erik....@gmail.com]

Hi,

I am a C++ developer mainly working in real-time systems (both hard and soft) and Linux systems/network programming. One sorely needed feature to be able to steer clear of naked pthread mutexes is the possibility to configure priority ceiling or priority inheritance on a std::mutex. Alternatively, a std:: wrapper for a pthread_mutex_t so it easily can be used with std::lock_guard or std::scoped_lock.

Is there any plans to extend the std::threads library with such support, on OS:es that support priority inheritance mutexes?

Se also

http://stackoverflow.com/questions/43234293/default-priority-inheritance-policy-of-pthread-mutexes-on-linux

[Nicol Bolas]

And what about platforms that aren't POSIX? The standard has to provide cross-platform behavior.

A POSIX-specific wrapper is not a good idea for the standard library. It's a fine idea for a regular library, though. And it's not hard to write a POSIX mutex wrapper that is Lockable.

[erik....@gmail.com]

OK, if we absolutely cannot have support for wrapping pthread mutexes in the std library, let's forget about that part. But having a way of requesting prio inheritance on a std::mutex would be necessary for some applications. With 'some', I mean almost all applications that share locks between threads of different priority.

[Vicente J. Botet Escriba]

Le 11/04/2017 à 11:20, erik....@gmail.com a écrit :
> Hi,
>
> I am a C++ developer mainly working in real-time systems (both hard
> and soft) and Linux systems/network programming. One sorely needed
> feature to be able to steer clear of naked pthread mutexes is the
> possibility to configure priority ceiling or priority inheritance on a
> std::mutex. Alternatively, a std:: wrapper for a pthread_mutex_t so it
> easily can be used with std::lock_guard or std::scoped_lock.
>
> Is there any plans to extend the std::threads library with such
> support, on OS:es that support priority inheritance mutexes?
>
>

Hi, there are some proposals for thread attributes. If this ends by
being adopted, I believe we could take the same approach for mutexes.

P0320R1 Thread Constructor Attributes
P0484R0 Enhancing Thread Constructor Attributes

Vicente

[Erik Alapää]

Sounds good! In principle, it should not be too hard to do on e.g. Linux (pthreads, futexes). I assume most platforms that support prio ceiling or prio inheritance provide something similar to the Posix mechanisms for configuring mutexes.

--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/LYR5EANJKhs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/626cb97c-0eb4-3194-30e8-89245de2dc60%40wanadoo.fr.

[Patrice Roy]

I agree with Vicente; priority inheritance protocols might be another interesting case where we the kind of solutions we will end up with for thread attributes might be applicable.

Erik, if you could submit (it can be a simple direct email to me, maybe to Vicente too) an example of code where the features you have in mind would come into play, such that I can see what kind of user code you see right now, I would be interested. It might not be what ends up beoing proposed, but it can be useful and informative.

Cheers!

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

[Erik Alapää]

Hi,

I can try to describe one scenario, the scenario I am working on now. It is more of a 'helicopter view' than code would be. If necessary, I can write some code also.

I am working on soft real-time Linux network measurement application that should scale from low-end 1-core machines up to future multicore machines (32 cores or more, both NUMA and SMP).

For handling many UDP streams, low- and high-bandwidh, we divide workload so each worker thread handles its subset of the streams. Further, we separate sender and receiver worker threads. On multicore machines, we will use one worker thread per CPU core available, but obviously not on 1-core machines.

For high performance, the workers must have Linux realtime priority, typically SCHED_FIFO or SCHED_RR. The other threads in the application (main thread, statistics collector threads) are low-prio SCHED_OTHER threads. 

Now, the problem: The low and high-prio threads share mutex locks. Consider a 1-core machine and this scenario, with 1 high-prio sender worker, 1 high-prio receiver worker, and a low-prio statistics thread.

1. Statistics thread goes to work to process statistics, acquires stats lock L.

2. Receiver worker wants to push stats, tries to acquire L and blocks.

3. Sender worker gets scheduled in since it is high-prio and is not blocking on L.

4. Stats thread cannot run, but holds L. This means that receiver worker (high-prio) cannot run for a long time, if sender worker runs for a long time. Receiver socket buffers in kernel overflow, and kernel drops packets.

The scenario above is not dependency inversion, but similar to it. If L had prio ceiling or prio inheritance configured, the stats thread would temporarily be raised to high-prio, and could do its work and promptly release the lock.

Let me know if anything is unclear.

--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/LYR5EANJKhs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp328Ff6xT2vgxiVrTUDhrq4aXfAipJKd9-JtSscU9RpNg%40mail.gmail.com.