Philippe Gerum wrote: > On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> The steps now: >>>>> >>>>> - we implement the automatic switchback of shadow nrt threads to >>>>> secondary mode, upon return from Xenomai (primary) syscalls. I am >>>>> working on this. The most significant impact is on userland, due to the >>>>> fastsynch support, actually. Kernel-wise, it's rather straightforward. >>>>> The only exception to this would be when the caller owns an exclusive >>>>> resource (like a mutex), in which case the mode downgrade should be >>>>> postponed until the syscall releasing the last resource held returns. >>>> Kernel is clear, but user space sounds indeed interesting. I guess we >>>> need an out-of-band channel to tell the kernel about pending >>>> user-space-only lock ownerships when calling some unrelated syscall. How >>>> does your current approach look like? >>> I want to keep things simple: shadow nrt will go through the syscalls >>> for acquisition/release of owned resources, instead of fastsynchs. >> Then I'll have to pick this up as that will very likely create unhappy >> customers. In fact, the majority of our Xenomai threads are nrt (yeah, >> that happens if you convert existing applications). > > I would understand that people do not want to bother that much with > using the right kind of threads between shadow nrt and plain linux > within the context of an initial port, but at some point, the code > should be made consistent with respect to the real use. > > If there is a problem with auto-shadowing in the POSIX skin, or > sched_setscheduler() or whatever, then it should be addressed, but we > just can't pile up code only to satisfy such a corner case, i.e. > situations where applications create Xenomai nrt threads without actual > need for this, to make them run in secondary mode only, without > requiring a single primary-mode service (hence wanting hard to keep > __xn_exec_current for RTDM).
The scenario is not that simple - unfortunately. > > So, I will merge the bits I have in mind as a first step, because they > satisfy the normal usage of Xenomai threads. I will certainly ACK any > improvement to this code which keeps the original fastsynch optimization > for nrt threads, provided the feature/code overhead ratio seems correct. Fine with me. >>>> For the use case of an enforced primary >>>> mode switch-back, add a new service - if it is really required. >>>> rt_task_set_mode is about static property switching, so adding T_PRIMARY >>>> here was already a bad idea from that perspective. >>>> >>> There is no such limitation to rt_task_set_mode(), and T_CONFORMING is >>> not meant to be used blindly. So, I will stick with this interface. >> T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the >> latter, it is a unique chance to finally drop that misplaced interface >> from rt_task_set_mode. It's asymmetric and does not really fit into the >> "true" modes that this interface controls. >> > > So, basically T_LOCK is a static switch for you? You mean that locking > the scheduler is a static property of any thread? Same for T_NOSIG and > blocking asynchronous calls? Look, I designed this interface after the > pSOS equivalent, and I can assure you that this was indeed meant to be a > mean to control dynamic properties. Those modes are not static but they can be applied symmetrically and do not change due to other influences. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
