From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28233 invoked by alias); 10 May 2012 18:32:31 -0000 Received: (qmail 28224 invoked by uid 22791); 10 May 2012 18:32:29 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 May 2012 18:32:16 +0000 From: "chris.hall at highwayman dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/7007] PTHREAD_EXPLICIT_SCHED not honored after 'attr' is initialized to defaults Date: Thu, 10 May 2012 18:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: chris.hall at highwayman dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00161.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=7007 Chris Hall changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris.hall at highwayman | |dot com --- Comment #2 from Chris Hall 2012-05-10 18:32:10 UTC --- POSIX is wonderfully vague in this area. While pthread_attr_init() is definite about the result being the defaults for all attributes, it is silent on what happens when any one of the connected scheduling attributes -- inheritance, scope, policy and params -- are changed. Amongst the difficulties: (1) if the default is PTHREAD_INHERIT_SCHED, what are the scope, policy and params set to ? They obviously cannot reflect what a thread is going to receive. They could (sensibly) be the defaults if PTHREAD_EXPLICIT_SCHED were then to be set. But POSIX doesn't quite say that. IMO, it would make life easier if the default were to be specified to be PTHREAD_EXPLICIT_SCHED -- but it isn't. (2) one would hope that after setting PTHREAD_EXPLICIT_SCHED the scope, policy and params would then be the defaults... but POSIX doesn't say. If those attributes are initialised that way, then the semantics are straightforward. If not, then there's an issue if any of those attributes are set before PTHREAD_EXPLICIT_SCHED is. In any case, POSIX leaves it open for some implementation to require the scope, policy and params to be set explicitly if PTHREAD_EXPLICIT_SCHED is set. (3) where there is a choice between PTHREAD_SCOPE_SYSTEM and PTHREAD_SCOPE_PROCESS, POSIX is silent on what happens when the scope is changed. If the the default policy and params were to be different for different scopes (and POSIX neither allows nor disallows this), should changing the scope change the "defaults" ? (Not many systems seem to support more than one scope, but that doesn't change the basic problem.) (4) POSIX specifies that the params are at a minimum the sched_priority -- though it does not specify a meaning for that for SCHED_OTHER. It is clearly allowing for there to be additional, implementation-defined param fields. When setting SCHED_XXX policy, are the params then set to defaults for that policy ? If not, then the application needs to have perfect knowledge of the local system if it is to set any policy other than the default. I have an application where PTHREAD_SCOPE_SYSTEM is the obvious choice... but given the ambiguities, I have struggled to find a POSIX-safe way to do this. In the end I have simply assumed that the policy and params used by the main thread will be suitable for PTHREAD_SCOPE_SYSTEM, so I can set PTHREAD_EXPLICIT_SCHED, and then all of scope, policy and params to unambiguous values. Which has the happy side effect of avoiding this particular "bug". Anyway... my point is that this whole area is a steaming pit of poorly defined icky-ness, and I suggest it would be no bad thing if glibc took a lead on sorting out. For my money, I would go with: * disallowing PTHREAD_INHERIT_SCHED as a default. * defining the setting of scope to, as a side effect, set the system default policy and params for that scope... * defining the setting of policy to, as a side effect, set the system default params for that policy... * ... or a new function which sets scope, policy and params all in one got, and invent PTHREAD_SCOPE_DEFAULT and SCHED_DEFAULT, so that (by using NULL to mean default params) an application can unambiguously set as much scheduling attributes as it wishes, allowing for many things to be implementation defined, without requiring the application to have perfect knowledge. Chris -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.