Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Hi,
>> On 03.12.2009, at 14:14, Gilles Chanteperdrix 
>> < 
>>  > wrote:
>>> Wolfgang Mauerer wrote:
>>>> Hi,
>>>> Gilles Chanteperdrix wrote:
>>>>> Wolfgang Mauerer wrote:
>>>>>> So that means, in essence, that you would accept probabilistic
>>>>>> algorithms in realtime context?
>>>>> Ah, today's troll!
>>>> though it seems that I have to replace Jan this time ;-)
>>>>> As I think I explained, the use of a seqlock in real-time context  
>>>>> when
>>>>> the seqlock writer only happens in linux context is not  
>>>>> probabilistic.
>>>>> It will work every time the first pass.
>>>> I still don't see why it should succeed every time: What about
>>>> the case that the Linux kernel on CPU0 updates the data, while
>>>> Xenomai accesses them on another CPU? This can lead to
>>>> inconsistent data, and they must be reread on the Xenomai side.
>>> Yeah, right. I was not thinking about SMP. But admit that in this  
>>> case,
>>> there will be only one retry, there is nothing pathological.

that's right. Which makes it bounded again, so it's maybe
the best way to go.
>>>> I'm asking because if this case can not happen, then there's
>>>> nothing left to to as I have the code already at hand.
>>> You have reworked the nucleus timers handling to adapt to this new
>>> real-time clock ?
>> Nope. Sorry, I was a bit unclear: I'm just referring to the gtod  
>> syscall that does the timer handling, Not any other adaptions.
> Ok, but what good is the gtod syscall if you can not use it as a time
> reference for other timing related services?

it suffices for our project's current purposes ;-)

But it's certainly not the full solution. Before, we
should have a decision wrt. the design issues, but I
won't be able to continue working on this before
mid of next week to look at the changed required for timer
handling and come up with code.

Cheers, Wolfgang

Xenomai-core mailing list

Reply via email to