[RTnet-developers] Joint threads

[Vareka, B. <BV...@am...>]

I moved this over from Rtnet-users because this seems the more appropriate
board.  Yes, I have thought about how to do this and at the moment I've
written a first stab at the code but I have yet to put together a system to
test it on.  The crux of the changes are as follows:
1) add a -j option to tdmacfg for 'slots' which takes the joint slot id.  It
will be required that the slot you want to reference to must have already
been defined before you define the joint slot.  Had not yet though about the
actual tdma.conf file but this should be pretty straight forward.

2) The tdma_config struct adds an additional int field called jointslot to
the set_slot union.  A value between 0 and MaxSlots (but not 1) indicates a
desire to be coupled.  Default is -1 (no coupling).

3) Because of the special role of the default NRT slot (1) and the fact that
a mechanism already exists for it to 'share' slot 0, I have strictly
forbidden the option to link slot 1 to other slots or other slots to it.
Also, since it's already NRT, there is no likely benefit in jointing it to
other slots for speed and latency purposes. 

4) Modify the tdma_slot by changing the 'queue' member to be a pointer to a
rtskb_prio_queue and add an additional actual rtskb_prio_queue called
myqueue.

5) By default, slot->queue just points to &slot->myqueue.  

6) The act of joining is achieved by changing slot->queue to point to
another pre-existing slot's myqueue member.  

7) the rest of the tdma_slot structs for the two joint slots are not
identical because this is where things like offset, period and phasing info
are kept and those are different for the two slots.  Only the
rtskb_prio_queue is common between them.  Note that I didn't really
appreciate this until I looked closely at the NRT example.  There things are
different because there never really is a slot 1 for the default case but
here we want the slots to really exist, we just want them to use the same
message queue.

8) If you remove a slot which is jointed to another slot but you're not the
reference, then you just delete normally.  But if others have queue pointer
pointing to your myqueue object then all those slots have their queue's
redirected to their own myqueue objects.  Obviously, care is taken that this
is done when ref_count is 0 so we don't corrupt a loop in progress.

9) The only other impact is a few function calls which currently have
&slot->queue which need to be changed to slot->queue since it's a pointer
already.

As is typical, I've got several other high priority projects going at once
so I suspect I won't have this tested and ready for a week or so.



Regards,
Bill



-----Original Message-----
From: Jan Kiszka [mailto:ki...@rt...] 
Sent: Tuesday, August 16, 2005 4:37 PM
To: Vareka, Bill
Cc: 'rtn...@li...'
Subject: Re: [RTnet-users] Slots, threads, and all that.

Vareka, Bill wrote:
> I just finished adding a section to the rtai wiki on rtnet.  The link is
> http://www.rtai.dk/cgi-bin/gratiswiki.pl?RTnet

Thanks for your contribution!

> I needed to work through how slots, slot buffers, threads, sockets, and
> priorities worked so that I could figure out how to meet my fairly severe
> scheduling needs.  Needless to say, this was a bit of a challenge but I

:)

Good work!

> believe I have correctly captured the standard RTmac/TDMA implementation.
If
> you're interested, give it a read and if there is anything I got wrong,
let
> me know.

As it's a wiki, I dared to mess around a bit. I removed some obsolete
stuff, straightened some terms and added a few explanations. No
guarantees as well, it was a quick hack.

Your commitment on a TDMA extension regarding "joint slots", as I would
call it now, will be warmly welcome! Do you already have an idea, how to
extend the configuration interface (tdmacfg)? Also, some syntax
extension for tdma.cfg would be useful. My spontaneous idea would be to
assign further slots to an existing one be means of an additional
tdmacfg parameter expecting the target slot id.

Looking forward to your patch! If questions regarding the TDMA code etc.
arrise, feel free to ask.

Jan