[ag-automation] application layer use cases for fieldbus stack

[Peter Soetens]

On Tuesday 10 July 2007 18:28:09 Robert Schwebel wrote:
> Hi Peter,
>
> On Tue, Jul 10, 2007 at 05:10:37PM +0200, Peter Soetens wrote:
> > Why would you lock the group across busses? I would expect individual
> > locks for each bus, as the messages from different busses come in
> > asynchronously (i.e. arbitrarily in time) anyway. The only thing you
> > want to prevent is that variable 'v' is not being overwritten by an
> > incomming message from v's bus (or is overwritten by another thread
> > simultaneously).
>
> Because the application doesn't know which bus a variable comes from, it
> is a pure configuration issue.

ok.

>
> > I'd say, whatever you do, don't use locks.
>
> I wouldn't implement it with locks internally; if we want to unify the
> streaming + shared memory cases, the idea would be to having TPU buffers
> internally with use counts, plus the TPU object switching pointers to
> "valid" ones in an atomic way.

ok.

>
> > Your old approach (one big lock) worked always but is not very
> > performant, but that's about how far you can get safely with locks:
> > adding more fine grained locks will improve performance but also lead
> > to deadlocks or priority inversions sooner or later.
>
> Exactly. For the read case it would work perfectly without locks, but
> I'm not sure about the scenarios for write-TPUs.
>
> > We're using these approaches to avoid using locks:
> >
> > 1. Use callbacks to read bus
> > This allows to read data from incoming TPUs in a thread-safe way, as
> > long as all the callbacks are serialised. This won't work in use cases
> > A and B though.
> >
> > 2. Use FIFOs to write bus
> > When you pv_set() new data, the data is pushed in a fifo, which
> > serialises all access, the fifo is emptied by the bus thread. This
> > works in all three cases.
> >
> > 3. Use lock-free algorithms to share process images (= pv groups) among
> > threads. This works in all three cases, but you need to read
> > (-modify-write) the process image as a whole.
> >
> > The disadvantage of points 2 and 3 is more memory usage.
>
> Hmm, I'll have to think about it a little bit more (have to leave for
> now). It would be cool if we could find an interface which allows to
> switch the mechanics behind the scenes, purely by configuration. There
> are single threaded applications out there with only one bus connected,
> and I'd like to see them being possible with the same code as in a
> complicated scenario, but being optimized on compile time.

This is a 'dream' I have heard before when developing frameworks for embedded.
If you standardise on the API, different libs can fill it in and offer 
single-thread/multi-thread solutions.

>
> > They are realistic, but not recommended. In Orocos, we use DataObjects
> > to share process images among threads (case A) and Events (similar to
> > boost::signals) to serialise updates with a (periodic) thread (case B
> > and C).
>
> I've looked at the OROCOS docs yesterday, but had the impression that
> you don't really care about such little implementation details as real
> fieldbus interfaces :-) So it would be cool if we could merge our ideas
> here...

:-) Actually, our components do have a CAN interface using Peak CAN and CANPie 
as backends, and there's where my limited fieldbus experience come from. We 
are definately overdoing it with respect to super embedded nodes, but once in 
a multi-threaded environment, the advantages become apparant.

>
> > This is an example of the 'read process image', modify it, and write it
> > back as a whole.
>
> Doesn't sound good; think of situations like the netX, where we have 32
> kB SRAM buffers in the CPU, probably mappable as 8 buffers containing a
> 4k page; I'd like to be able to use them as TPU buffer space. There is
> not much space for complete-process-image copies if you have only 8
> buffers :-)

I'm sure you're not multithreading in that case and can leave the whole 
locking or RCU stuff behind.

Peter

-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>