Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>>> On the one hand you make complicated code (which will be costly on low
>>> end hardware) to avoid shutting interrupts around a few assignments, but
>>> on the other hand you leave an architecture specific function pointer
>>> call where we want a fast behaviour on average (remember, we do all this
>>> to avoid a system call, which is only a few hundreds nanoseconds on your
>>> big iron x86), and where we have a generic fast replacement. Sometimes,
>>> I do not understand your logic.
>> But using the same argument, you could get rid of Linux vsyscall based
> I do not see your point, the Linux code does not go a long way to make
> lockless code, it simply turns off interrupts around the gtod data
> update, which is really reasonable given the size of the masking
> section. The reading is lockless, the writing is not.
I was referring to the argument that system calls are so fast that
replacing gtod with a syscall-less version that uses function
pointer dereferencing instead does not make much of a difference.
Be it as it may, I need to check how far our budget can cover
the (much more comprehensive) modifications required for the
solution suggested by you. Let's see.
Xenomai-core mailing list