I've updated the code, which fixes a bug and removes some compiler warnings. The bug is:<br><br>diff --git a/cpukit/posix/include/rtems/posix/threadsup.h b/cpukit/posix/include/rtems/posix/threadsup.h<br>index 5409c81..eae55aa 100644<br>
--- a/cpukit/posix/include/rtems/posix/threadsup.h<br>+++ b/cpukit/posix/include/rtems/posix/threadsup.h<br>@@ -72,7 +72,7 @@ typedef struct {<br>   Chain_Control           Cancellation_Handlers;<br>   <br>   /** This is the thread key value chain's control */<br>
-  Chain_Control          *the_chain;<br>+  Chain_Control          the_chain;<br> <br> } POSIX_API_Control;<br><br>It surprises me that this bug haven't broken any test before...Luckily, I find it when I try to remove compiler's warning. However, there is still a discards `const' warning at cpukit/posic/src/keysetspecific.c:52. I find it's difficult to remove this warning, not sure whether it matters a lot.<br>
<br>And I've done the space comparison between one-rbtree and one-rbtree-per-thread. It seems that I make this comparion more cumbersome than it should be...my conlusion is both approaches need O( m * t ) memory. Here are the details:<br>
<br>Suppose there is m keys and t threads, each threads have m key values, that is there are n=m * t nodes in one-rbtree approach, and m nodes in each rbtree in one-rbtree per-thread approach.<br> - space of one rbtree approach:<br>
S1 = m * sizeof( POSIX_Keys_Control ) + m * t * sizeof( POSIX_Keys_Rbtree_node ) + t * sizeof( Chain_Control )<br> - space of one-rbtree per-thread:<br>S2 = m * sizeof( POSIX_Keys_Control ) + m * t * sizeof( POSIX_Keys_Rbtree_node ) + t * sizeof( RBTree_Control )<br>
<br>---NOTE---<br>0. These two approach's POSIX_Keys_Control struct are the same:<br>typedef struct {<br>   Objects_Control     object;<br>   void (*destructor) (void *);<br> }  POSIX_Keys_Control;<br><br>1. one-rbtree approach's POSIX_Keys_Rbtree_node is:<br>
<br>typedef struct {<br>  Chain_Node ch_node;<br>  RBTree_Node rb_node;<br>  pthread_key_t key;<br>  Objects_Id thread_id;<br>  void *value;<br> }  POSIX_Keys_Rbtree_node;<br><br>while one-rbtree-per-thread's POSIX_Keys_Rbtree_node is like:<br>
<br>typedef struct {<br>
  RBTree_Node rb_node;<br>
  pthread_key_t key;<br>
  void *value;<br>
 }  POSIX_Keys_Rbtree_node;<br><br>there is no Chain_Node and Objects_Id member here. The season of include those two members is one-rbtree approach uses a chain to keep track each thread's key nodes. However, in one-rbtree-per-thread approach each thread has a tree to do that work, then there is no need to include those two members.<br>
<br>3. On sparc, the sizes of these structure are:<br>    one-rbtree's POSIX_Keys_Rbtree_node: 36<br>    one-rbtree-per-thread's POSIX_Keys_Rbtree_node: 24<br>    Chain_Control: 12<br>    RBTree_Control: 24<br>    POSIX_Keys_Control: 20<br clear="all">
---END of NOTE---<br><br>If take the size of these structure on Sparc as an example, the result is:<br> - space of one rbtree approach:<br>   S1 = m * 20 + m * t * 36+ t * 12<br>
 - space of one-rbtree per-thread:<br>  
S2 = m * 20 + m * t * 24 + t * 24<br>and S1 - S2  = 12 * t * ( m - 1). The one-rbtree approach needs more memory. However, both approaches need O( m * t ) memory. <br><br>-- <br>Best wishes!<br>Zhongwei Yao<br><br>