Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DSDP - Real-Time Software Components (RTSC) » xdc.runtime.knl
xdc.runtime.knl [message #380] Wed, 05 November 2008 17:42 Go to next message
Bill Mills is currently offline Bill Mills
Messages: 1
Registered: July 2009
Junior Member
The POSIX thread brings up the possible expansion on xdc.runtime to
include abstract task/thread services. What public resource can we use to
explore the scope of this. Would the scope just be threading/tasking
primitives? Would timer callbacks or events be in scope? Can we sketch
out what the API would look like?

The xdc.runtime API's are setup to be used directly by the components and
are slightly abstracted from the actual execution context. To me this is
exactly correct. I, as a component writer, don't want to worry about how
Gate needs to get its job done for the execution context I am in. It may
need to disable interrupts, it may need to grab a mutext, or (in the
degenerate case) it may need to do nothing at all. All I need to know is
I need to grab it before I access something that may cross execution
contexts. (I also need to know to release it :) ).

So who is the target of the xdc.runtime.knl API's? Is it the integration
code that needs to create threads to satisfy the components execution
requirements or is it the components themselves that need to schedule work
at a later time or context? Is it both?

So the basic question (above what is covered or not) is xdc.runtime.knl a
slight abstraction over task/thread managment or is it a model of a
component's usage pattern of execution contents. (For example the
handlers of a reactor pattern. I am not saying synchronous dispatch is
correct; just an example.)

In defense of timers: Having written networking protocols as components
before I know timer requests/callback events are something I would want to
use from inside a component. It is a level above the basics offered by
xdc.runtime but in my use something I needed inside the component more
than a way to create/delete threads. create/delete/schedule threads comes
up more when I build the subsystem wrapper and have chosen to instanciate
the components a specific way.
Re: xdc.runtime.knl [message #384 is a reply to message #380] Wed, 05 November 2008 23:35 Go to previous messageGo to next message
Dave Russo is currently offline Dave Russo
Messages: 172
Registered: July 2009
Senior Member
Bill Mills wrote:
> The POSIX thread brings up the possible expansion on xdc.runtime to
> include abstract task/thread services. What public resource can we use
> to explore the scope of this. Would the scope just be threading/tasking
> primitives?
The current thinking is that the scope would include very basic
threading and thread synchronization primitives; only that sufficient to
support (say) a simple network stack such as TI's NDK or the OSAL needed
by Codec Engine. So the ability to create multiple threads, wait on
conditions, delete threads, and manage thread local storage are probably
required.

Based on the previous POSIX discussion, it should also be sufficient to
enable a 100% portable implementation of POSIX 1003.1c.

>Would timer callbacks or events be in scope? Can we sketch
> out what the API would look like?
Callbacks are certainly in scope. However, depending on the calling
context assumed by the callbacks and the functions callable from
callbacks, this might fall into the category of an enhancement of the
existing xdc.runtime.

>
> The xdc.runtime API's are setup to be used directly by the components
> and are slightly abstracted from the actual execution context. To me
> this is exactly correct. I, as a component writer, don't want to worry
> about how Gate needs to get its job done for the execution context I am
> in. It may need to disable interrupts, it may need to grab a mutext, or
> (in the degenerate case) it may need to do nothing at all. All I need
> to know is I need to grab it before I access something that may cross
> execution contexts. (I also need to know to release it :) ).
>
> So who is the target of the xdc.runtime.knl API's? Is it the
> integration code that needs to create threads to satisfy the components
> execution requirements or is it the components themselves that need to
> schedule work at a later time or context? Is it both?
Both (unless the design becomes overburdened). We need to keep it
_very_ basic, to be sure that implementations of the interfaces are
practical on resource constrained devices. If it is possible to build
more "conventional" threading APIs atop xdc.runtime.knl (as suggested by
the posix thread), then "integration" code may find it "easier" to use
the posix APIs.
>
> So the basic question (above what is covered or not) is xdc.runtime.knl
> a slight abstraction over task/thread managment or is it a model of a
> component's usage pattern of execution contents. (For example the
> handlers of a reactor pattern. I am not saying synchronous dispatch is
> correct; just an example.)
>
> In defense of timers: Having written networking protocols as components
> before I know timer requests/callback events are something I would want
> to use from inside a component. It is a level above the basics offered
> by xdc.runtime but in my use something I needed inside the component
> more than a way to create/delete threads. create/delete/schedule
> threads comes up more when I build the subsystem wrapper and have chosen
> to instanciate the components a specific way.
>
Perhaps the best way to move forward is to define the interface using
the RTSC IDL and attach it to a bugzilla enhancement for the runtime
component.
>
>
Re: xdc.runtime.knl [message #389 is a reply to message #384] Tue, 11 November 2008 08:17 Go to previous messageGo to next message
Michael Ambrus is currently offline Michael Ambrus
Messages: 9
Registered: July 2009
Junior Member
dave russo wrote:

> Bill Mills wrote:
>> The POSIX thread brings up the possible expansion on xdc.runtime to
>> include abstract task/thread services. What public resource can we use
>> to explore the scope of this. Would the scope just be threading/tasking
>> primitives?
> The current thinking is that the scope would include very basic
> threading and thread synchronization primitives; only that sufficient to
> support (say) a simple network stack such as TI's NDK or the OSAL needed
> by Codec Engine. So the ability to create multiple threads, wait on
> conditions, delete threads, and manage thread local storage are probably
> required.

> Based on the previous POSIX discussion, it should also be sufficient to
> enable a 100% portable implementation of POSIX 1003.1c.


One could extend that a little: Since application development based
strictly on POSIX 1003.1c is not very practical, the API I had in mind is
the complete POSIX 1003.1c and small pieces from POSIX 1003.1b. As in the
following:

http://kato.homelinux.org/~tinker/cgi-bin/wiki.pl/API

I.e. xdc.runtime.knl is what I'm planning to use as back-end to provide
the same API as above. Application programmers can then choose to use
which abstraction they want depending on preference or legacy.

>>Would timer callbacks or events be in scope? Can we sketch
>> out what the API would look like?
> Callbacks are certainly in scope. However, depending on the calling
> context assumed by the callbacks and the functions callable from
> callbacks, this might fall into the category of an enhancement of the
> existing xdc.runtime.


Or you can build up you own extension based on a creating a temporary
thread and the following function:

http://www.opengroup.org/onlinepubs/009695399/functions/pthr ead_cond_timedwait.html

>>
>> The xdc.runtime API's are setup to be used directly by the components
>> and are slightly abstracted from the actual execution context. To me
>> this is exactly correct. I, as a component writer, don't want to worry
>> about how Gate needs to get its job done for the execution context I am
>> in. It may need to disable interrupts, it may need to grab a mutext, or
>> (in the degenerate case) it may need to do nothing at all. All I need
>> to know is I need to grab it before I access something that may cross
>> execution contexts. (I also need to know to release it :) ).
>>
>> So who is the target of the xdc.runtime.knl API's? Is it the
>> integration code that needs to create threads to satisfy the components
>> execution requirements or is it the components themselves that need to
>> schedule work at a later time or context? Is it both?
> Both (unless the design becomes overburdened). We need to keep it
> _very_ basic, to be sure that implementations of the interfaces are
> practical on resource constrained devices. If it is possible to build
> more "conventional" threading APIs atop xdc.runtime.knl (as suggested by
> the posix thread), then "integration" code may find it "easier" to use
> the posix APIs.


Agreed, that's the approach I would recommend as well. Depending on which
scope one has and which architecture aspect one tends to favour from the
application perspective, the answer might be different. Personally I would
prefer portability over performance (up to a certain level of penalty).

I.e. if I understand the callback timer issue correctly (which I might
not, since I'm Swedish and I sometimes misunderstand stuff ;) ), I would
make a small class or function that implements the service you require
based on a few pThreads primitives. I don't object having a primitive
similar to this in xdc.runtime.knl, but as Dave mentioned it's a good idea
to start with a very limited set of primitives and to initially put
whatever abstraction is needed on top of that.

Then if someone finds a certain primitive well motivated on the
xdc.runtime.knl level, we can extend it's definition later on.

>>
>> So the basic question (above what is covered or not) is xdc.runtime.knl
>> a slight abstraction over task/thread managment or is it a model of a
>> component's usage pattern of execution contents. (For example the
>> handlers of a reactor pattern. I am not saying synchronous dispatch is
>> correct; just an example.)
>>
>> In defense of timers: Having written networking protocols as components
>> before I know timer requests/callback events are something I would want
>> to use from inside a component. It is a level above the basics offered
>> by xdc.runtime but in my use something I needed inside the component
>> more than a way to create/delete threads. create/delete/schedule
>> threads comes up more when I build the subsystem wrapper and have chosen
>> to instanciate the components a specific way.
>>
> Perhaps the best way to move forward is to define the interface using
> the RTSC IDL and attach it to a bugzilla enhancement for the runtime
> component.
Re: xdc.runtime.knl [message #393 is a reply to message #389] Thu, 13 November 2008 13:00 Go to previous messageGo to next message
Alex Godofsky is currently offline Alex Godofsky
Messages: 1
Registered: July 2009
Junior Member
Original developer of the package chiming in...

Michael Ambrus wrote:

> One could extend that a little: Since application development based
> strictly on POSIX 1003.1c is not very practical, the API I had in mind is
> the complete POSIX 1003.1c and small pieces from POSIX 1003.1b. As in the
> following:

> http://kato.homelinux.org/~tinker/cgi-bin/wiki.pl/API

> I.e. xdc.runtime.knl is what I'm planning to use as back-end to provide
> the same API as above. Application programmers can then choose to use
> which abstraction they want depending on preference or legacy.

I don't believe it's feasible to actually do so. xdc.runtime.knl is
pretty minimal, so a lot of thread attributes would be hard to emulate
efficiently and correctly. In addition, the behavior of the objects
provided is not specified nearly as tightly as POSIX objects are, so
guaranteeing compliance would be a lot harder.

(For example, POSIX cvars are required to respect the underlying
scheduling policy and not set it on their own; the provided BIOS 6
implementation is currently FIFO because there weren't sufficient hooks
into the BIOS 6 kernel to use its scheduler.)

This looseness was deliberate; as Dave said in another thread:
> The idea of xdc.runtime.knl is to define a small base set of threading
> interfaces (not implementations) that can be supported by virtually any RTOS
> (including an RTOS for non-TI devices). A requirement is that very small
> footprint implementations of these interfaces are possible. This will allow
> code written to xdc.runtime.knl interfaces to be, in a practical sense, 100%
> portable: the code can be used on virtually any CPU, from 16-bit micro-
> controllers up (from any manufacturer).

Then again, I don't actually know exactly how hard a 100% compliant POSIX
is to write; I've never done it.
Re: xdc.runtime.knl [message #693 is a reply to message #393] Tue, 02 December 2008 12:47 Go to previous message
Michael Ambrus is currently offline Michael Ambrus
Messages: 9
Registered: July 2009
Junior Member
Alex Godofsky wrote:

> I don't believe it's feasible to actually do so. xdc.runtime.knl is
> pretty minimal, so a lot of thread attributes would be hard to emulate
> efficiently and correctly. In addition, the behavior of the objects
> provided is not specified nearly as tightly as POSIX objects are, so
> guaranteeing compliance would be a lot harder.

There are not that many attributes that are hard to emulate. Many of them
concerns pretty basic things like stack size, priority e.t.a. Most kernels
I know of have corresponding mechanisms. There are other aspects (and some
attributes) harder to mimic though.

> (For example, POSIX cvars are required to respect the underlying
> scheduling policy and not set it on their own; the provided BIOS 6
> implementation is currently FIFO because there weren't sufficient hooks
> into the BIOS 6 kernel to use its scheduler.)

Scheduling policy is a concept (one of few) impossible to emulate if it's
not supported by the underlying kernel. If the ambition is to have 100%
compliance then it would require a change to the back-end kernel. However
I think most application programmes would be fine with whatever scheduling
policy is in there, as long as one knows which is supported and which is
not. A mechanism detecting unsupported usage would cover most cases I can
think of.

The point from where I'm standing is, that the implementation does not
have to be 100% complaint. From a portability viewpoint it's possible to
move away *from* a partly compliant implementation but not necessarily
*to*. Which is most important I believe is up to each and everyone to
decide. With an obscure API however, people are tied and can't move either
to or from. In that case it doesn't matter much that it's free.
Previous Topic:Dumping modules/interfaces in a package
Next Topic:TCF as RTSC examle?
Goto Forum:
  


Current Time: Mon Jul 28 08:39:26 EDT 2014

Powered by FUDForum. Page generated in 0.02687 seconds