[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
removing taskvares (was Re: rtems_filesystem_current issues)
- Date: Mon, 28 Oct 2002 16:53:36 +1100
- From: cjohns at cybertec.com.au (Chris Johns)
- Subject: removing taskvares (was Re: rtems_filesystem_current issues)
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 cybertec.com.au