removing taskvares (was Re: rtems_filesystem_current issues)

Chris Johns cjohns at
Mon Oct 28 05:53:36 UTC 2002

Till Straumann wrote:
> As for supporting other librarie's globals: IMO, the most important goal
> is not to punish threads who do not use e.g. RPC with context switch
> overhead related to RPC. OTOH, a thread who decides to use (again,
> for example,) RPC, should be willing to accept a little higher penalty.

The issue with this type of rule and why taskvars fails as a concept is 
the switch out time for a task, eg RPC, is the switch in time for 
another task.  RPC may be willing to pay the price, how-ever the task 
being switch too may not. Suddenly things are not deterministic.

We must settle on a solution that is scalable for all cases and IMO have 
0 switching overhead.

The User Extensions API seems to fit the bill, is stable and documented.

> This leads to a model with one pointer (to each thread's RTEMS-reent
> structure) which is switched very fast.

Check the TCB's "extensions" array and see if this is suitable. It seems 
suitable for this job.

> The RTEMS-reent structure then
> can have one (or a couple of) slots for pointers to "extension lists".

I wonder if this does not solve the problem just moves it. You could end 
up creating a specialised subset of the User Extensions API. I would be 
concerned about adding another API while we have one that should do the job.

A pointer is only half the problem. You need "construction" and 
"destruction" support to setup and clean up memory used. For example 
setting up memory may not be a straight forward malloc and memcpy of an 
existing global structure as pointers may be present. A deep copy maybe 

I think things that are libc specific should be grouped, how-ever the 
remainder can directly use the User Extensions API.

> -> context switch is fast in any case.
> -> tasks who need access to library globals have to look them up
> note that in most cases the global variables are not accessed very
> frequently and it's less painful to increase lookup time than context
> switch latency.

The User Extension API has no switch cost. The cost to access via the 
indirect pointer is a little higher than directly but this seems to be 
the price to pay. This seems to fit what are asking for.

  Chris Johns, cjohns at

More information about the users mailing list