M. Koehrer wrote: > Hi Herman and Jan, > > thanks for your replies. > I agree that is the best to do an approach that avoids critical sections. > However, we have here the typical "historical heritage". Parts of this code > have > been ported from another system (where they worked with cli/sti). > Other parts are generated from a third party code generator. > This code generator (which is not in my hand) is designed primarily > for offline simulation within a single task. > Thus, the guys that programmed that, did not care about multi thread > programming. > The programs write the results into output variables. > To avoid critical section I have now to do either > an additional copy (also quite expensive) of the output data to a location > where I can work without any risk of being interrupted or I lock the access > to the data. > That means either I do lots of additional copy actions (also quite expensive) > or I work > with the critical region. > > Thus for me it is not an either - or - option. > I can not optimize the code to be 100% free of critical sections (however it > can be done in > some parts..). That means I still have to count on the IPC provided by the OS.
OK, seeing your motivation, I would now like to roughly sketch to issue I see about futexes for Xenomai: You need user space and kernel space working on the same piece of memory atomically AND you need to get the contention case right. The latter is tricky because Xenomai does -for various reasons like robustness- the sequence "try to acquire, fail, enqueue waiter, suspend" under one common lock. As with futexes that "try to acquire" may cause page faults (in buggy programs), you need to redesign things. I have no model for such a redesign at hand (nor would I like to think deeper and detract myself from other pending stuff), but my feeling is that it will be at least, well, challenging. Looking at kernel futex code and watching its pending issues, you may see that this is actually not so much Xenomai-specific. Anyway, go wild people, maybe I'm just too pessimistic. :) Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
