[RTnet-developers] Joint threads
Brought to you by:
bet-frogger,
kiszka
|
From: Vareka, B. <BV...@am...> - 2005-08-17 00:38:39
|
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 |