pthread_getattr_np does not work

xuelin.tian xuelin.tian at qkmtech.com
Sun Sep 24 06:08:32 UTC 2017


So, is there a substitute function for this in RTEMS, without modifying the source code?
 
 
------------------ Original ------------------
From:  "Joel Sherrill"<joel at rtems.org>;
Date:  Sun, Sep 24, 2017 00:15 AM
To:  "xuelin.tian"<xuelin.tian at qkmtech.com>; 
Cc:  "Sebastian Huber"<sebastian.huber at embedded-brains.de>; "users at rtems.org"<users at rtems.org>; 
Subject:  Re: Re: pthread_getattr_np does not work

 


On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian <xuelin.tian at qkmtech.com> wrote:
Thanks so much for your test. 


No problem. Just trying to help.
 
The parts of this structure I care about most are the stackaddr and stacksize (and guardsize maybe), where stackaddr always returns 0. The value of stacksize is either 8192 or 0, based on the fact that this attribute structure is retrieved from POSIX_Init or other pthreads in my system (maybe I use pthread_create in a wrong way...). 


Without looking at the code, 8192 is almost certainly the port specific default 
stack size since it is normally a value like that. A stack size request of anything
less than the recommended minimum will always get you an allocation of the
minimum. So 0 or 8192 might simply indicate whether the structure is explicitly 
initialized via pthread_attr_init() or filled in explicitly by the application with
the minimum stack size constant. 
 


So, from the result you post, the stackaddr is 0 too, which means this element is not supported in rtems, or there is something wrong with this function?




This means the user application didn't specify the stack area in RTEMS. Since
this method is "NP", there is no standard specifying the behavior.


This method doesn't exist on FreeBSD and appears to only exist in Linux and
RTEMS. If there is consensus that it should behave the same on Linux and
RTEMS, then there should be a ticket filed with (hopefully) patches. <hint>


It isn't a complicated method and all if should take is filling in the attribute
structure with different fields in the TCB. I think it primarily parrots back
the attribute structure passed to pthread_create().


Also writing the man page for the RTEMS POSIX manual would be appreciated.


Nothing like wandering into something that is even beyond unspecified in
POSIX to a method that is explicitly non-portable for fun. :)


--joel


--joel
 
 
------------------ Original ------------------
From:  "Joel Sherrill"<joel at rtems.org>;
Date:  Fri, Sep 22, 2017 10:15 PM
To:  "xuelin.tian at qkmtech.com"<xuelin.tian at qkmtech.com>; 
Cc:  "Sebastian Huber"<sebastian.huber at embedded-brains.de>; "users at rtems.org"<users at rtems.org>; 
Subject:  Re: Re: pthread_getattr_np does not work

 
The test does verify the values. I don't see a specific case of creating a threadwith a non-standard stack value and verifying that value in the task but the
test creates a thread which retrieves its values and verifies many (most, all?)
of them:


(gdb) 
Thread - pthread_getattr_np - Verify value
46        sc = pthread_getattr_np( Thread_id, &attr );
(gdb) 
47        rtems_test_assert( sc == 0 );
(gdb) 
52        puts( "Thread - pthread_setschedparam: Setting highest priority SCHED_FIFO" );
(gdb) p attr
$1 = {is_initialized = 1, stackaddr = 0x0, stacksize = 8192, 
  contentionscope = 0, inheritsched = 2, schedpolicy = 2, schedparam = {
    sched_priority = 3, sched_ss_low_priority = 285216961, 
    sched_ss_repl_period = {tv_sec = 0, tv_nsec = 16}, 
    sched_ss_init_budget = {tv_sec = 0, tv_nsec = 1}, sched_ss_max_repl = 0}, 
  guardsize = 0, cputime_clock_allowed = 1, detachstate = 1, 
  affinitysetsize = 0, affinityset = 0x0, affinitysetpreallocated = {
    __bits = {0}}}



Clearly the attribute structure returned is not all zero.


I am not sure what you are seeing but it doesn't match what I see in
this test on the erc32.


--joel


On Fri, Sep 22, 2017 at 4:04 AM, xuelin.tian at qkmtech.com <xuelin.tian at qkmtech.com> wrote:
 OK, no problem, thanks anyway.
 


 Best wishes,
xuelin.tian at qkmtech.com


  
From: Sebastian Huber
Date: 2017-09-22 16:58
To: xuelin.tian at qkmtech.com; users at rtems.org
Subject: Re: pthread_getattr_np does not work


On 22/09/17 10:55, xuelin.tian at qkmtech.com wrote:
  
 > OK, I will try to do some fix on this function. And if Sherrill and 
 > you have time, please take some time on this. Thanks a lot.
  
 No, sorry. I have no time to fix this.
  
 -- 
 Sebastian Huber, embedded brains GmbH
  
 Address : Dornierstr. 4, D-82178 Puchheim, Germany
 Phone   : +49 89 189 47 41-16
 Fax     : +49 89 189 47 41-09
 E-Mail  : sebastian.huber at embedded-brains.de
 PGP     : Public key available on request.
  
 Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
 
 

_______________________________________________
 users mailing list
 users at rtems.org
 http://lists.rtems.org/mailman/listinfo/users



 



             自动判断 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语      自动选择 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语     有道翻译 百度翻译 必应翻译 谷歌翻译 谷歌翻译(国内)   翻译    朗读 复制     正在查询,请稍候……    重试      朗读 复制        复制      朗读 复制      via    译
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170924/b7c888d3/attachment-0001.html>


More information about the users mailing list