removing taskvares (was Re: rtems_filesystem_current issues)

[Chris Johns]

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 
needed.

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 cybertec.com.au