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

[Robert Schwebel]

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.

> 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.

> 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.

> 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...

> 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 understand your use cases from a 'low level API' point of view, but I 
> would not recommend them. If you really want these cases anyway, I 
> would 'recommend' one big lock and take the performance hit it offers. 
> That's the only way you'll be guaranteed on the safe side.

Ok, I'll think it over again tomorrow. Thanks for your input, I hope we
can gain mutual advantage out of these ideas & what orocos has already
investigated.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9