Mark,
Am 26.04.2013 um 11:38 schrieb Mark Wendt <wendt.m...@gmail.com>: > On Fri, Apr 26, 2013 at 1:47 AM, Michael Haberler <mai...@mah.priv.at>wrote: > >> Ken, >> >> Am 25.04.2013 um 01:11 schrieb Kenneth Lerman <kenneth.ler...@se-ltd.com>: >> >> I'm only addressing this question here: >> >> >> Just noting that the work on RTAPI/HAL has brought with it two >> capabilities which relate to the theme; most of this has been discussed and >> done off-list, but since the them comes up I respond to it even if it isnt >> completely done yet: >> >> first, RTAPI is now multi-instance capable (several RTAPI instances on >> _one_ machine); instances being identified by an integer id (NB this doesnt >> make NML multi-instance but I hope NML will be history this year in this >> branch so I dont bother anymore) >> > > > Michael, > > Just being curious, how does the multi-instance RTAI keep from banging > heads with each other? Lets say we have two instances of RTAI running, how > does RTAI keep itself from requiring the same resource as another RTAI This multi-instance capability is independent of any specific RTOS and works with all flavors (RTAI, Xenomai any style, RT-PREEMPT) even across flavors; you can have a Xenomai kernel, a few Xenomai user RT instances and a few Posix instances running simultaneously without things going haywire. Not that that makes any sense, I just mention this works too. > instance at the same time, "resources" really translates into threads and shared memory shared memory is an easy case because all shm is allocated at setup time; there is no runtime memory allocation in RTAPI land even if it might be supported as per API description, and it is fact an unnecessary use of a non-portable OS API, which is why I have removed this and replaced by standard Posix shm and a single helper driver for kernel threads just fine, with lots of RTOS-dependent code becoming history in one go. all that was needed to coordinate shared memory is clean up the hodge-podge allocation of shared memory keys here and there, and make an instance id part of the key as for threads, that is quite easy to disambiguate as well > and still maintain the real-time domain of > having the resource "NOW", when it's needed? there is no 'NOW' allocation in allow of LinuxCNC, provided you mean 'NOW' to mean either task or shm allocation 'within a time critical thread'. It is all preallocated before the game starts, and _outside_ of any RT threads, so any fears for collision may be safely put to rest. That case simply doesnt exist, and I cant conceive one were it suddenly might be needed. - Michael > > Mark > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
