------=_Part_2059_88907687.1491902427220
Content-Type: multipart/alternative;
 boundary="----=_Part_2060_1232360326.1491902427221"

------=_Part_2060_1232360326.1491902427221
Content-Type: text/plain; charset=UTF-8

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





--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/41dc3025-be7f-4c6a-a61c-c21386f59169%40isocpp.org.

------=_Part_2060_1232360326.1491902427221
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I am a C++ developer mainly working=
 in real-time systems (both hard and soft) and Linux systems/network progra=
mming. One sorely needed feature to be able to steer clear of naked pthread=
 mutexes is the possibility to configure priority ceiling or priority inher=
itance 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.</div><=
div><br></div><div>Is there any plans to extend the std::threads library wi=
th such support, on OS:es that support priority inheritance mutexes?</div><=
div><br></div><div>Se also</div><div><br></div><div>http://stackoverflow.co=
m/questions/43234293/default-priority-inheritance-policy-of-pthread-mutexes=
-on-linux<br></div><div><br></div><div><br></div><div><br></div><div><br></=
div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/41dc3025-be7f-4c6a-a61c-c21386f59169%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/41dc3025-be7f-4c6a-a61c-c21386f59169=
%40isocpp.org</a>.<br />

------=_Part_2060_1232360326.1491902427221--

------=_Part_2059_88907687.1491902427220--

.

------=_Part_1178_2113756828.1491918748651
Content-Type: multipart/alternative;
 boundary="----=_Part_1179_490314663.1491918748651"

------=_Part_1179_490314663.1491918748651
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c6c1db78-6bfa-4339-8a29-6b3e1c30d24f%40isocpp.org.

------=_Part_1179_490314663.1491918748651
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">And what about platforms that aren&#39;t POSIX? The standa=
rd has to provide cross-platform behavior.<br><br>A POSIX-specific wrapper =
is not a good idea for the standard library. It&#39;s a fine idea for a reg=
ular library, though. And it&#39;s not hard to write a POSIX mutex wrapper =
that is Lockable.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c6c1db78-6bfa-4339-8a29-6b3e1c30d24f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6c1db78-6bfa-4339-8a29-6b3e1c30d24f=
%40isocpp.org</a>.<br />

------=_Part_1179_490314663.1491918748651--

------=_Part_1178_2113756828.1491918748651--

.

------=_Part_9004_638609566.1491919872886
Content-Type: multipart/alternative;
 boundary="----=_Part_9005_780964635.1491919872887"

------=_Part_9005_780964635.1491919872887
Content-Type: text/plain; charset=UTF-8

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.


On Tuesday, April 11, 2017 at 3:52:28 PM UTC+2, Nicol Bolas wrote:
>
> 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.
>

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3664938a-c9b1-43fe-974c-194e116aca3d%40isocpp.org.

------=_Part_9005_780964635.1491919872887
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK, if we absolutely cannot have support for wrapping pthr=
ead mutexes in the std library, let&#39;s forget about that part. But havin=
g a way of requesting prio inheritance on a std::mutex would be necessary f=
or some applications. With &#39;some&#39;, I mean almost all applications t=
hat share locks between threads of different priority.<div><br></div><div><=
br>On Tuesday, April 11, 2017 at 3:52:28 PM UTC+2, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">And what about plat=
forms that aren&#39;t POSIX? The standard has to provide cross-platform beh=
avior.<br><br>A POSIX-specific wrapper is not a good idea for the standard =
library. It&#39;s a fine idea for a regular library, though. And it&#39;s n=
ot hard to write a POSIX mutex wrapper that is Lockable.<br></div></blockqu=
ote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3664938a-c9b1-43fe-974c-194e116aca3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3664938a-c9b1-43fe-974c-194e116aca3d=
%40isocpp.org</a>.<br />

------=_Part_9005_780964635.1491919872887--

------=_Part_9004_638609566.1491919872886--

.

Le 11/04/2017 =C3=A0 11:20, erik.alapaa@gmail.com a =C3=A9crit :
> Hi,
>
> I am a C++ developer mainly working in real-time systems (both hard=20
> and soft) and Linux systems/network programming. One sorely needed=20
> feature to be able to steer clear of naked pthread mutexes is the=20
> possibility to configure priority ceiling or priority inheritance on a=20
> std::mutex. Alternatively, a std:: wrapper for a pthread_mutex_t so it=20
> easily can be used with std::lock_guard or std::scoped_lock.
>
> Is there any plans to extend the std::threads library with such=20
> support, on OS:es that support priority inheritance mutexes?
>
>
Hi, there are some proposals for thread attributes. If this ends by=20
being adopted, I believe we could take the same approach for mutexes.

P0320R1     Thread Constructor Attributes
P0484R0     Enhancing Thread Constructor Attributes

Vicente

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@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.f=
r.

.

--94eb2c0557683e4dd5054ceb798b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.



On Tue, Apr 11, 2017 at 9:49 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Le 11/04/2017 =C3=A0 11:20, erik.alapaa@gmail.com a =C3=A9crit :
>
>> 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 t=
o
>> 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 bein=
g
> adopted, I believe we could take the same approach for mutexes.
>
> P0320R1     Thread Constructor Attributes
> P0484R0     Enhancing Thread Constructor Attributes
>
> Vicente
>
> --
> 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/is
> ocpp.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-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/626cb97c-0eb4-3194-30e8-
> 89245de2dc60%40wanadoo.fr.
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAByO_s1%2BPcc4Jw8%3DGVd2tRKFY8j49R1HZn5ZfsuLom_=
d8U_yiQ%40mail.gmail.com.

--94eb2c0557683e4dd5054ceb798b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sounds good! In principle, it should not be too hard to do=
 on e.g. Linux (pthreads, futexes). I assume most platforms that support pr=
io ceiling or prio inheritance provide something similar to the Posix mecha=
nisms for configuring mutexes.<div><br></div><div><br></div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Apr 11, 2017 at 9:=
49 PM, Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"mailto:vic=
ente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Le 11/04/20=
17 =C3=A0 11:20, <a href=3D"mailto:erik.alapaa@gmail.com" target=3D"_blank"=
>erik.alapaa@gmail.com</a> a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am a C++ developer mainly working in real-time systems (both hard and sof=
t) and Linux systems/network programming. One sorely needed feature to be a=
ble 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::loc=
k_guard or std::scoped_lock.<br>
<br>
Is there any plans to extend the std::threads library with such support, on=
 OS:es that support priority inheritance mutexes?<br>
<br>
<br>
</blockquote></span>
Hi, there are some proposals for thread attributes. If this ends by being a=
dopted, I believe we could take the same approach for mutexes.<br>
<br>
P0320R1=C2=A0 =C2=A0 =C2=A0Thread Constructor Attributes<br>
P0484R0=C2=A0 =C2=A0 =C2=A0Enhancing Thread Constructor Attributes<br>
<br>
Vicente<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LYR5EANJKhs/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/s=
td-proposals<wbr>/LYR5EANJKhs/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/626cb97c-0eb4-3194-30e8-89245de2dc60%=
40wanadoo.fr" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/626cb97c-0eb4-3194-30e8-<wbr=
>89245de2dc60%40wanadoo.fr</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAByO_s1%2BPcc4Jw8%3DGVd2tRKFY8j49R1H=
Zn5ZfsuLom_d8U_yiQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAByO_s1%2BPc=
c4Jw8%3DGVd2tRKFY8j49R1HZn5ZfsuLom_d8U_yiQ%40mail.gmail.com</a>.<br />

--94eb2c0557683e4dd5054ceb798b--

.

--001a114e248216a958054cec13dd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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!

2017-04-11 15:49 GMT-04:00 Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr>:

> Le 11/04/2017 =C3=A0 11:20, erik.alapaa@gmail.com a =C3=A9crit :
>
>> 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 t=
o
>> 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 bein=
g
> adopted, I believe we could take the same approach for mutexes.
>
> P0320R1     Thread Constructor Attributes
> P0484R0     Enhancing Thread Constructor Attributes
>
> Vicente
>
> --
> 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-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/626cb97c-0eb4-3194-30e8-
> 89245de2dc60%40wanadoo.fr.
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp328Ff6xT2vgxiVrTUDhrq4aXfAipJKd9-JtSscU9R=
pNg%40mail.gmail.com.

--001a114e248216a958054cec13dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I agree with Vicente; priority inheritance proto=
cols might be another interesting case where we the kind of solutions we wi=
ll end up with for thread attributes might be applicable.<br><br></div>Erik=
, if you could submit (it can be a simple direct email to me, maybe to Vice=
nte 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 c=
an be useful and informative.<br><br></div>Cheers!<br></div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">2017-04-11 15:49 GMT-04:00 Vicen=
te J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"mailto:vicente.botet@w=
anadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</span>:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D"">Le 11/04/2017 =C3=A0 11:20, <=
a href=3D"mailto:erik.alapaa@gmail.com" target=3D"_blank">erik.alapaa@gmail=
..com</a> a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am a C++ developer mainly working in real-time systems (both hard and sof=
t) and Linux systems/network programming. One sorely needed feature to be a=
ble 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::loc=
k_guard or std::scoped_lock.<br>
<br>
Is there any plans to extend the std::threads library with such support, on=
 OS:es that support priority inheritance mutexes?<br>
<br>
<br>
</blockquote></span>
Hi, there are some proposals for thread attributes. If this ends by being a=
dopted, I believe we could take the same approach for mutexes.<br>
<br>
P0320R1=C2=A0 =C2=A0 =C2=A0Thread Constructor Attributes<br>
P0484R0=C2=A0 =C2=A0 =C2=A0Enhancing Thread Constructor Attributes<br>
<br>
Vicente<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/626cb97c-0eb4-3194-30e8-89245de2dc60%=
40wanadoo.fr" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/626cb97c-0eb4-3194-30e8-<wbr=
>89245de2dc60%40wanadoo.fr</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp328Ff6xT2vgxiVrTUDhrq4aXfAipJK=
d9-JtSscU9RpNg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp328Ff6xT2v=
gxiVrTUDhrq4aXfAipJKd9-JtSscU9RpNg%40mail.gmail.com</a>.<br />

--001a114e248216a958054cec13dd--

.

--94eb2c124a245b4c74054cf338ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.





On Wed, Apr 12, 2017 at 1:01 AM, Patrice Roy <patricer@gmail.com> wrote:

> 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 t=
o
> 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!
>
> 2017-04-11 15:49 GMT-04:00 Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr>:
>
>> Le 11/04/2017 =C3=A0 11:20, erik.alapaa@gmail.com a =C3=A9crit :
>>
>>> 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 b=
e
>>> 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
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/626cb97c-0eb4-3194-30e8-89245
>> de2dc60%40wanadoo.fr.
>>
>
> --
> 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-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAKiZDp328Ff6xT2vgxiVrTUDhrq4a
> XfAipJKd9-JtSscU9RpNg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp328F=
f6xT2vgxiVrTUDhrq4aXfAipJKd9-JtSscU9RpNg%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAByO_s1im3D48KXUMMKr75EZri6FhCE4dNthAqyNb615d3P=
bNg%40mail.gmail.com.

--94eb2c124a245b4c74054cf338ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I can try to describe one scenario,=
 the scenario I am working on now. It is more of a &#39;helicopter view&#39=
; than code would be. If necessary, I can write some code also.</div><div><=
br></div><div>I am working on soft real-time Linux network measurement appl=
ication that should scale from low-end 1-core machines up to future multico=
re machines (32 cores or more, both NUMA and SMP).</div><div><br></div><div=
>For handling many UDP streams, low- and high-bandwidh, we divide workload =
so each worker thread handles its subset of the streams. Further, we separa=
te sender and receiver worker threads. On multicore machines, we will use o=
ne worker thread per CPU core available, but obviously not on 1-core machin=
es.</div><div><br></div><div>For high performance, the workers must have Li=
nux 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.=C2=A0</div><div><br></div><div>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.</div><div><br></div><div>1. Statistics t=
hread goes to work to process statistics, acquires stats lock L.</div><div>=
2. Receiver worker wants to push stats, tries to acquire L and blocks.</div=
><div>3. Sender worker gets scheduled in since it is high-prio and is not b=
locking on L.</div><div>4. Stats thread cannot run, but holds L. This means=
 that receiver worker (high-prio) cannot run for a long time, if sender wor=
ker runs for a long time. Receiver socket buffers in kernel overflow, and k=
ernel drops packets.</div><div><br></div><div>The scenario above is not dep=
endency inversion, but similar to it. If L had prio ceiling or prio inherit=
ance configured, the stats thread would temporarily be raised to high-prio,=
 and could do its work and promptly release the lock.<br></div><div><br></d=
iv><div>Let me know if anything is unclear.</div><div><br></div><div><br></=
div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Wed, Apr 12, 2017 at 1:01 AM, Patrice Roy <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:patricer@gmail.com" target=3D"_blank">patr=
icer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><div>I agree with Vicente; priority inheritance protocols=
 might be another interesting case where we the kind of solutions we will e=
nd up with for thread attributes might be applicable.<br><br></div>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 woul=
d be interested. It might not be what ends up beoing proposed, but it can b=
e useful and informative.<br><br></div>Cheers!<br></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote"><span class=3D"">2017-04-11 15:49 GM=
T-04:00 Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"mailto:vi=
cente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;<=
/span>:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><span>Le =
11/04/2017 =C3=A0 11:20, <a href=3D"mailto:erik.alapaa@gmail.com" target=3D=
"_blank">erik.alapaa@gmail.com</a> a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am a C++ developer mainly working in real-time systems (both hard and sof=
t) and Linux systems/network programming. One sorely needed feature to be a=
ble 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::loc=
k_guard or std::scoped_lock.<br>
<br>
Is there any plans to extend the std::threads library with such support, on=
 OS:es that support priority inheritance mutexes?<br>
<br>
<br>
</blockquote></span>
Hi, there are some proposals for thread attributes. If this ends by being a=
dopted, I believe we could take the same approach for mutexes.<br>
<br>
P0320R1=C2=A0 =C2=A0 =C2=A0Thread Constructor Attributes<br>
P0484R0=C2=A0 =C2=A0 =C2=A0Enhancing Thread Constructor Attributes<br>
<br>
Vicente</span><span><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><br=
>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span></span><spa=
n class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/626cb97c-0eb4-3194-30e8-89245de2dc60%=
40wanadoo.fr" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/626cb97c-0eb4-3194-30e8-8924=
5<wbr>de2dc60%40wanadoo.fr</a>.<br>
</span></blockquote></div><br></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LYR5EANJKhs/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/L=
YR5EANJKhs/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp328Ff6xT2vgxiVrTUDhrq4aXfAipJK=
d9-JtSscU9RpNg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAKiZDp328Ff6xT2vgxiVrTUDhrq4a<wbr>XfAipJKd9-JtSscU9RpN=
g%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAByO_s1im3D48KXUMMKr75EZri6FhCE4dNth=
AqyNb615d3PbNg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAByO_s1im3D48KXU=
MMKr75EZri6FhCE4dNthAqyNb615d3PbNg%40mail.gmail.com</a>.<br />

--94eb2c124a245b4c74054cf338ed--

.