Re: pthread_attr_setsched behaviour

["Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>]

[Siddhesh, thanks for adding me to the thread]

On Thu, Apr 18, 2013 at 4:55 AM, Siddhesh Poyarekar
<siddhesh.poyarekar@gmail.com> wrote:
> OK, *now* I've added Michael Kerrisk to cc :)
>
> Siddhesh
>
> On 17 April 2013 18:19, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
>> On Tue, Apr 16, 2013 at 03:32:11PM +0200, Manuel Traut wrote:
>>> Hi,
>>>
>>> i just recognized, that calling:
>>>
>>> ret |= pthread_attr_setschedpolicy (..)
>>> ret |= pthread_attr_setschedparam (..)
>>> ret |= pthread_create (..)
>>>
>>> doesn't return an error and the values set by pthread_attr_setschedparam and
>>> pthread_attr_setschedpolicy aren't applied to the thread.
>>>
>>> The APPLICATION USAGE of the functions say:
>>>
>>>    After  these attributes have been set, a thread can be created with the
>>>    specified attributes using pthread_create(). Using these routines  does
>>>    not affect the current running thread.
>>>
>>> So I didn't expect that I need to call:
>>> pthread_attr_setinheritsched before pthread_create.

I agree that when one reads the specifications (and the man pages) for
pthread_attr_setsched*(), there is no clue that
pthread_attr_setinheritsched().

Whoever, when one reads the spec for pthread_attr_setinheritsched()
(and also the man page), it becomes clear that one must use
pthread_attr_setinheritsched(). I'm not quite sure why that is so, but
 it is what the spec clearly requires.

As Rich noted, the thing to do is improve the man page. Ehe EXAMPLE in
the pthread_setschedparam(3) page does show the use of
pthread_attr_setinheritsched() and the pthread_attr_setschedpolicy(3)
page also points to that example, but the point should be more
explicit in the main text of the DESCRIPTION in those two pages.

>>> I would like to improve the current behaviour, with a little patch;
>>> please give me some directions...
>>>
>>> Is there a reason why e.g. pthread_attr_set_schedparam doesn't set
>>> iattr->flags |= ATTR_FLAG_NOTINHERITSCHED
>>
>> The POSIX specification doesn't tell us that we ought to do this.  If
>> we do, we might end up breaking compatibility.

Indeed the specification seems pretty clear that you should not do it.

>>> Or is it better to return an error code in pthread_attr_setschedparam, etc if
>>> ATTR_FLAG_NOTINHERITSCHED isn't set?
>>
>> This is wrong since one is allowed to set NOTINHERITSCHED after
>> setschedparam.
>>
>>> If both is bad, at least the man page should mention the need of calling
>>> pthread_attr_setinheritsched..
>>
>> This is the best option currently.  I've added Michael Kerrisk to cc;
>> he maintains the man pages.

I have applied the patch below.

Thanks for the report.

Cheers,

Michael


--- a/man3/pthread_attr_setschedparam.3
+++ b/man3/pthread_attr_setschedparam.3
@@ -71,6 +71,17 @@ As can be seen, only one scheduling parameter is supported.
 For details of the permitted ranges for scheduling priorities
 in each scheduling policy, see
 .BR sched_setscheduler (2).
+
+In order for the parameter setting made by
+.BR pthread_attr_setschedparam ()
+to have effect when calling
+.BR pthread_create (3),
+the caller must use
+.BR pthread_attr_setinheritsched (3)
+to set the inherit-scheduler attribute of the attributes object
+.I attr
+to
+.BR PTHREAD_EXPLICIT_SCHED .
 .SH RETURN VALUE
 On success, these functions return 0;
 on error, they return a nonzero error number.
diff --git a/man3/pthread_attr_setschedpolicy.3
b/man3/pthread_attr_setschedpolicy.3
index 46e5c2f..f96ad42 100644
--- a/man3/pthread_attr_setschedpolicy.3
+++ b/man3/pthread_attr_setschedpolicy.3
@@ -69,6 +69,17 @@ returns the scheduling policy attribute of the
thread attributes object
 .IR attr
 in the buffer pointed to by
 .IR policy .
+
+In order for the policy setting made by
+.BR pthread_attr_setschedpolicy ()
+to have effect when calling
+.BR pthread_create (3),
+the caller must use
+.BR pthread_attr_setinheritsched (3)
+to set the inherit-scheduler attribute of the attributes object
+.I attr
+to
+.BR PTHREAD_EXPLICIT_SCHED .
 .SH RETURN VALUE
 On success, these functions return 0;
 on error, they return a nonzero error number.