On Tue, Mar 27, 2007 at 12:29:13PM +0200, COLSON Nicolas RD-TECH-GRE
wrote:
Thanks for the answer.
Would it be possible to have a look at the status report on what’s
done and what’s left to be done for m-blocks. We may consider
contributing to the code.
Thanks! See below.
We are particularly interested in:
- the metadata exchange for sending reconfiguration orders
This should fall out naturally. Each message contains a data and a
metadata attribute. The interpretation of the data and metadata is up
to you. You are also free to create, delete, connect and disconnect
mblocks at runtime.
- the interface with gr-blocks for using previously build modules
See my message from yesterday. There will be a subclass of mblock
that knows how to embedded a flowgraph within an mblock, and will
provide a means for sending and receiving data between the mblock and
the flow graph.
- an effective scheduler capable of assuring on the fly
reconfiguration withouth data interruption
With regard to mblocks, this won’t be a problem. Johnathan C. is
currently working on this feature for classic GNU Radio blocks. He
and I are scheduled to talk about this later today. Most of the work
is already done.
Here’s what’s left to do with mblocks (first pass):
(1) Implement a “thread per mblock” scheduler. This allows mblocks to
fully exploit SMP/SMT machines, and allows mblocks to block for i/o
while handling messages (it also simplifies the implementation.)
I expect to have this finished by the end of this week.
(2) Locking on traversal and modification of the internal data
structure that describes the mblock interconnections. I expect to
have this finished by the end of this week.
When (1) and (2) are complete the foundation of the system is basically
working.
(3) Define interface for supporting timer messages, and implement the
mechanism. That is, provide a way for mblocks to have one-time or
periodic Timeout messages sent to them.
(4) Create a tool (script) that compiles protocol class definitions
into C++ code.
(5) Cache the resolution of connections between mblocks. The code
will work without this, but caching the location of the ultimate
recipient of a message allows us to remove lots of runtime overhead
from the “send” primitive.
(6) syntactic sugar for connect / disconnect. Allow the connection to
be expressed as a single string, e.g. connect(“self:control to
transmitter:cs”)
(7) Implement serialize and deserialize (marshalling) for pmt objects.
This will allow them to be passed across process or machine boundaries.
(8) Write a couple of example applications.
(9) Create a subclass of mblock that knows how to embed a flow graph.
Create the associated sinks and sources. Write an example that uses
these.
(10) Document the differences between what’s implemented and the BBN
paper.
In addition to the mblock basics these things remain:
-
inband signaling for USRP (design currently in progress)
-
Consider revising the mblock composition API such that it is more
declarative than functional. This could facilitate configuring
and running a system of mblocks across a cluster or other h/w that
lacks shared memory between processing elements.
-
Consider implementing pmt data types in a shared memory segment
with appropriate thread-safe reference counting. This would allow
very fast exchange of (large) messages on SMP/SMT machines.
I’m sure I’ve left things out…
Eric