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

[Burkhard Carstens]

[..]
> > 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!
I don't know, what you mean by "uniterruptible counter". A timestamp is 
just, well, similar to the "now" function in fpc.

Check the book, they provide some examples for this. See chapter 7 
"Time, Delay and Deffered Work", page 190ff talks about "busy waiting".
Also check page 196ff "Kernel Timers".
"Kernel timer" and "Blocking I/O" (page 147ff) for the sample-routine 
would make a good team for this, I guess..

>
> 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...

Do you have the 3rd Edition? This one covers Kernel up to 2.6.10.

> 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?
No, don't do that!! Read chapter 5 "Concurrency and Race Conditions", 
especially "Spinlock and Atomic Context" (page 118ff) 

Good luck!

Regards
  Burkhard