Re: [Fwd: [Adeos-main] LRTBF par-log.c & adeos_critical_enter question]

[Philippe Gerum <rpm@xenomai.org>]

Hannes Mayer wrote:
> Hi Kristian!
> 
> Thanks a lot for your reply!
> 
> Kristian Benoit wrote:
> 
>> On Mon, 2005-07-11 at 20:00 +0200, Hannes Mayer wrote:
>>
>>> Dear Kristian!
>>>
>>> Philippe (Gerum) just notified me, that you're probably not subscribed
>>> to the Adeos-Main maillist, so I'm forwarding my mail to the list.
>>> I hope that is OK.
>>
>>
>> Now I am :) thanks.
>>
>>> After adeos_critical_enter, interrupts are disabled anyway (right?), 
>>> so no
>>> modification of read_pos or write_pos is possible and reading over the
>>> proc file is not disturbed.
>>>
>>> Furthermore in read_proc you reset disable_timer only after the complete
>>> buffer was read via the proc file:
>>>
>>>     if (read_pos == write_pos) {
>>>         disable_timer = 0;
>>
>>
>>
>> Exactly, that's the reason.
> 
> 
> So you disable writing to the buffer by design and not because it would 
> interfer
> with read_proc.
> 
>>> The problem:
>>> While some user-space app is reading from the proc file, nothing is 
>>> written
>>> to the buffer and this causes data loss.
>>
>>
>>
>> As it actually is only used by lrtbf in the way I wrote it, it does not
>> really matters. And in that particular case it is better like that as I
>> insert the module. Do some job on the target. Then when the job is done,
>> I start reading from the proc file and dont get post job interrupt data
>> in the buffer.
>>
>>
>>> IMO, it would be best, if writing to the buffer is not disabled in 
>>> read_proc.
>>> In the actual data copying action in read_proc/while-loop no 
>>> interrupt can
>>> interfer - and if not everything from the buffer was read in the 
>>> first place,
>>> there is no problem if some data is added to the buffer until the 
>>> next read
>>> action occurs.
>>
>>
>>
>> I must admit that it is not really made to be read more than once. I
>> thought of doiing a double buffering method, but I did'nt much time to
>> implement an unnecessary feature. (unnecessary in the actual state)   
> 
> 
> Yeah, I was already too much focused on my application - in your app that
> problem is not critical.
> 
> I've done some tests and I'm able to have an interrupt frequency of up to
> more than 40kHz, writing data to the buffer, reading via an userspace app
> and writing to disk without losing data on my P3/450MHz box.
> (the traditional way, not with relayfs - will look into that soon)
> 
> I just have a followup to one of my orignal questions (maybe for Philippe):
> After adeos_critical_enter, all interrupts are disabled and are enabled
> again with adeos_critical_exit.
> The interrupts occuring during this time are not cached somewhere, 
> aren't they ?

Masked at CPU level. adeos_critical_xxx is intended for use with 
inter-cpu synchronization for mutual exclusion, IOW, the caller of 
adeos_critical_enter is guaranteed to be the only CPU running inside the 
section after the call returns, and until adeos_critical_exit is invoked 
to release this super-lock. Other CPUs are forced to spin on a barrier 
over an IPI handler while the initiating CPU proceeds inside the 
section. On UP systems, the same guarantee is given by simply masking 
the interrupts at CPU level.

> I mean, is it possible to get information on how many interrupts were 
> lost ?

Nope.

-- 

Philippe.