[Fwd: Re: [fpc-pascal] spin_lock]

[Alain Michaud]

(Burkhard: my mistake. Sorry )


Hi, 

thank you for your message. I find it VERY usefull! I have many
questions:

1--  Keep in mind that I need the processor for a period of 100
milisecond ONLY. After that, my process can be off for 10 seconds or
more... Between the 'critical sections', there is plently of time to put
everything back to normal, write to the disk, etc... 

2--
> So what about this:
> modify your drivers sample routine that it takes a timestamp 
> (time_for_next_sample) and returns a timestamp (last_sampled) together 
> with your voltage value. in the sample routine take your spin_lock, 
> loop until currenttime > time_for_next_sample, get your value, get a 
> timestamp, spin_unlock, return values;
> now your pascal program can call the sample-routine again with 
> time_for_next_sample:=first_time_stamp+(sampleIdx * deltaTime) ..
> This way, it's still the pascal program, that specifies the sampling 
> rate .. 
> 
> 
  
This is a great idea! I am a little bit scared to have to
write so many lines in C. But apart from that, this is a very good
idea...

The "time stamp" is a 64 bit uninterrruptible counter that counts the
processor clock. There is a GREAT package on lazarus called EpikTimer by
Tom Lisjak. I can use it as an example!   
 
  
3--
> That's understandable, me too. But I had to write a kernel driver for a 
> self-made pci board doing 2.6mbyte DMA data input constantly for 
> several hours. With the help of "Linux Device Drivers" book
> (read online: http://www.oreilly.com/catalog/linuxdrive3/book/index.csp)
> I managed to write that thing within less than a week, without having 
> written any piece o C code before .. 
> IOW, it's not that har

Oh yes! Don't worry. I have this book even in my bed. I have been on
this project for weeks now, and can not foresee the end of it... but I
guess I am old... That's a good excuse...

4--
> use nice to give your process the highest possible priority (-20)?
> But however, I guess kernel(drivers) still might jump in to respont to 
> any IRQs (e.g. from ISDN board) ...
> 
 
I will try that too. Thanks.  Even if it responds to an IRQ, if the
"scheduler" (forgot the exact name of this one, sorry) decides to send
it back to my "high priority" loop, then the delay may not be too long.
This is quite different than for example if it decides to redraw the
screen.

5-
What about the following (vicious and maybe stupid) idea:

I call the driver using IOCTL, then the driver will take the spinlock
and then return!

I do my thing in Pascal.

Later, I call the driver again using another IOCTL call and the driver
will release the lock!

I can not imagine that such thing would work. Would you?

Any way. I thank you for reading all this.

Cheers

Alain   

  


On Wed, 2006-05-31 at 00:49 +0200, Burkhard Carstens wrote:
> Am Dienstag, 30. Mai 2006 22:24 schrieb Alain Michaud:
> > > You might want to give some more details about your "situation".
> > > arch? os? and why would you do this? There might be a better
> > > solution.. than locking the hole system for 1/5 second ..
> > >
> > > Burkhard
> >
> > Hi,
> >
> > I feel a little bit guilty to use this list for my personal problems,
> > but here it is:
> >
> > I use one of those (ISA) I/O bards: I write or read from a port and
> > control a "slow" experiment. More details about the timing:
> >
> > I can trigger the experiment at any time I like. In fact, this is not
> > realy a "REAL TIME" experiment.  Typically I use the TTimer component
> > which will "fire" every 10 seconds os so. This is easy!
> >
> > Once the experiment has been started, then I monitor a voltage from
> > the same I/O board. Subsequently I plot the measured voltage
> > waveform, save the numbers on disk, wait for the laser to cool down,
> > and repeat the measurement. All this house cleaning is done AFTER the
> > experiment is finished therefore there is no timing problem. The only
> > 'critical' section is during the acquisition ('monitor') period. In
> > fact this not too critical either:
> >
> > After the experiment has been trigered, I want to read one value
> > every milisecond for a total period of 200 milisecond MAXIMUM.
> > Moreover the jitter (fluctuation) on the sampling can be as large as
> > 0.1 milisecond. This is very easy to do. In fact I can just do a loop
> > and monitor the time counter, and call the driver to do a read as
> > soon as one milisecond has elapsed!  I have done some tests already
> > and this will meet my requirement!  Now the problem...
> >
> > THE PROBLEM...
> >
> >  The problem: the problem is: even if the timing is not so critical
> > and the the experiment does not last for long, once it has started
> > then the processor should not leave and go answer the phone for
> > another process... I think that most process can be delayed for 200ms
> > but my acquisition loop should NOT be interrupted while it is doing
> > its thing.
> >
> > Now, I know that I can use spin-lock while I am in the device driver
> > in kernel space, but if I do that, then I have to take care of the
> > timing in the driver as well. It would be the driver who would be
> > responsible for the whole acquisition sequence.
> >
> > I would realy prefer to do the timing in my pascal program and call
> > the driver to read the bytes only. This would be easier to program!
> > and more flexible (not as fast of course but this is OK).
> 
> So what about this:
> modify your drivers sample routine that it takes a timestamp 
> (time_for_next_sample) and returns a timestamp (last_sampled) together 
> with your voltage value. in the sample routine take your spin_lock, 
> loop until currenttime > time_for_next_sample, get your value, get a 
> timestamp, spin_unlock, return values;
> now your pascal program can call the sample-routine again with 
> time_for_next_sample:=first_time_stamp+(sampleIdx * deltaTime) ..
> This way, it's still the pascal program, that specifies the sampling 
> rate .. 
> 
> 
> > The only way to acheive what I have just described is to disable the
> > interrupts or use a "spinlock". Again, I would prefer to do it in my
> > pascal code. I realy prefer programming Pascal than "kernel C"!
> 
> That's understandable, me too. But I had to write a kernel driver for a 
> self-made pci board doing 2.6mbyte DMA data input constantly for 
> several hours. With the help of "Linux Device Drivers" book
> (read online: http://www.oreilly.com/catalog/linuxdrive3/book/index.csp)
> I managed to write that thing within less than a week, without having 
> written any piece o C code before .. 
> IOW, it's not that hard.
> 
> And in kernel driver, you could take advantage of timers/softinterrupts
> 
> > Now I should mention that I am in Mandriva Linux, the kernel is
> > 2.6.12.
> >
> > I used to do this in Windows 3.1 and DOS. There were no problems. I
> > would just put $FA$ (CLI) and $FF$ (STI) that would disable and
> > enable interrupts, but now with Windows XP, those tricks are not
> > possible anymore!  This is what they call 'progress'.
> >
> > Question:
> >
> > Can I use "asm CLI end;"  and "asm STI end;" in my pascal code?
> 
> I don't think it's a good idea. think e.g. of disabling IRQs, then 
> accessing some memory that currently is paged out to swap file, the 
> kernel would need to page it back into ram, but can't read the disk 
> without IRQs
> 
> > Is there any trick that I can use to have high priority for a short
> > period of time (100ms)?
> 
> use nice to give your process the highest possible priority (-20)?
> But however, I guess kernel(drivers) still might jump in to respont to 
> any IRQs (e.g. from ISDN board) ...
> 
> >
> > Is there a way to suspend all other processes?
> - nice to set them to low priority
> - run as console-program in runlevel 3 or even 1 (without X / single 
> user mode)
> This would still leave the problem of any kernel driver blocking 
> 
> Burkhard
>