|
| Re: xdc.runtime.knl [message #384 is a reply to message #380] |
Thu, 06 November 2008 04:35   |
 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 13:17 |
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 18:00 |
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.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03367 seconds
] 
Search
Help
Register
Login
Home
