spin_lock

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

spin_lock

Alain Michaud
Hi,

would someone know how to execute: spin_lock spin_lock_init and
spin_unlock

I just want to disable the interrupts for 200 miliseconds maximum! This
is not too long and hopefuly, my system will not crash...  

Does someone has any experience with this kind of situation.

Sincerely

Alain Michaud





 



 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Burkhard Carstens-3
Am Dienstag, 30. Mai 2006 01:05 schrieb Alain Michaud:
> Hi,
>
> would someone know how to execute: spin_lock spin_lock_init and
> spin_unlock
>
> I just want to disable the interrupts for 200 miliseconds maximum!
> This is not too long and hopefuly, my system will not crash...

Well, 200 ms is about ages for the CPU/Kernel ..

> Does someone has any experience with this kind of situation.

This is not that easy: Is it only for UP or maybe also for SMP machines?
Basically, for x86 the "cli" and "sti" asm instructions do disable/
enable interrupts, but read about it before you try.
Currently, I do such stuff only inside a driver (Linux kernel:
spin_lock, or win98 vxd: cli/sti) and don't know about any user space
function for this.

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Marco van de Voort
[ Charset ISO-8859-15 unsupported, converting... ]

> Am Dienstag, 30. Mai 2006 01:05 schrieb Alain Michaud:
> > Hi,
> >
> > would someone know how to execute: spin_lock spin_lock_init and
> > spin_unlock
> >
> > I just want to disable the interrupts for 200 miliseconds maximum!
> > This is not too long and hopefuly, my system will not crash...
>
> Well, 200 ms is about ages for the CPU/Kernel ..
>
> > Does someone has any experience with this kind of situation.
>
> This is not that easy: Is it only for UP or maybe also for SMP machines?
> Basically, for x86 the "cli" and "sti" asm instructions do disable/
> enable interrupts, but read about it before you try.
> Currently, I do such stuff only inside a driver (Linux kernel:
> spin_lock, or win98 vxd: cli/sti) and don't know about any user space
> function for this.

FreeBSD has (in pthread.h):
int             pthread_spin_init(pthread_spinlock_t *, int);
int             pthread_spin_destroy(pthread_spinlock_t *);
int             pthread_spin_lock(pthread_spinlock_t *);
int             pthread_spin_trylock(pthread_spinlock_t *);
int             pthread_spin_unlock(pthread_spinlock_t *);
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Jonas Maebe-2

On 30 mei 2006, at 08:57, Marco van de Voort wrote:

>>
>> This is not that easy: Is it only for UP or maybe also for SMP  
>> machines?
>> Basically, for x86 the "cli" and "sti" asm instructions do disable/
>> enable interrupts, but read about it before you try.
>> Currently, I do such stuff only inside a driver (Linux kernel:
>> spin_lock, or win98 vxd: cli/sti) and don't know about any user space
>> function for this.
>
> FreeBSD has (in pthread.h):
> int             pthread_spin_init(pthread_spinlock_t *, int);
> int             pthread_spin_destroy(pthread_spinlock_t *);
> int             pthread_spin_lock(pthread_spinlock_t *);
> int             pthread_spin_trylock(pthread_spinlock_t *);
> int             pthread_spin_unlock(pthread_spinlock_t *);

Those (fortunately) do not disable interrupts. I can't imagine that  
any (generic) pre-emptively multitasked OS would allow a user space  
program to disable interrupts.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Burkhard Carstens-3
Am Dienstag, 30. Mai 2006 09:51 schrieb Jonas Maebe:

> On 30 mei 2006, at 08:57, Marco van de Voort wrote:
> >> This is not that easy: Is it only for UP or maybe also for SMP
> >> machines?
> >> Basically, for x86 the "cli" and "sti" asm instructions do
> >> disable/ enable interrupts, but read about it before you try.
> >> Currently, I do such stuff only inside a driver (Linux kernel:
> >> spin_lock, or win98 vxd: cli/sti) and don't know about any user
> >> space function for this.
> >
> > FreeBSD has (in pthread.h):
> > int             pthread_spin_init(pthread_spinlock_t *, int);
> > int             pthread_spin_destroy(pthread_spinlock_t *);
> > int             pthread_spin_lock(pthread_spinlock_t *);
> > int             pthread_spin_trylock(pthread_spinlock_t *);
> > int             pthread_spin_unlock(pthread_spinlock_t *);
>
> Those (fortunately) do not disable interrupts. I can't imagine that
> any (generic) pre-emptively multitasked OS would allow a user space
> program to disable interrupts.

exactly what I thought ..

Burkhard

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Alain Michaud
In reply to this post by Burkhard Carstens-3

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

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"!

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?

Is there any trick that I can use to have high priority for a short
period of time (100ms)?

Is there a way to suspend all other processes?

Any idea is welcome.

Thank-you for reading.

Alain Michaud





 



 



 

 


 

 

 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Marc Santhoff
Am Dienstag, den 30.05.2006, 16:24 -0400 schrieb Alain Michaud:
> 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:    

IMO this is your main problem: the rotten old board. ;)

To get away from "dangerous programming" I personally would solve it by
using an I/O-Board that drives Interrupts on the host computer. Even
cheap ones are able to make 1 ms timing.

Another hardware based solution would be to connect a microcomputer
board inbetween the computer and the sensor stuff. A little AVR or
similar can easily programmed to get one trigger command and then read
in values at 1ms timing for 200ms. Afterwards it can transfer data to
the host.

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

If the measure is extremely critical, why does the computer have other
tasks to do? Can't you use a dedicated machine for the measurement?

HTH,
Marc


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Joep L. Blom
Marc Santhoff wrote:

>Am Dienstag, den 30.05.2006, 16:24 -0400 schrieb Alain Michaud:
>  
>
>>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:    
>>    
>>
>
>IMO this is your main problem: the rotten old board. ;)
>
>To get away from "dangerous programming" I personally would solve it by
>using an I/O-Board that drives Interrupts on the host computer. Even
>cheap ones are able to make 1 ms timing.
>
>Another hardware based solution would be to connect a microcomputer
>board inbetween the computer and the sensor stuff. A little AVR or
>similar can easily programmed to get one trigger command and then read
>in values at 1ms timing for 200ms. Afterwards it can transfer data to
>the host.
>
>  
>
>>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.
>>    
>>
>
>If the measure is extremely critical, why does the computer have other
>tasks to do? Can't you use a dedicated machine for the measurement?
>
>HTH,
>Marc
>
>
>_______________________________________________
>fpc-pascal maillist  -  [hidden email]
>http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>  
>
Alain,
I think your problem id not hardware but software. Simply, Windows is
not a real-time operating system. You need an operating system (like
RTOS) that can set process priorities. Giving your process the highest
priority guarantees that no other process van interrupt your process.
There are some Linux flavors that also have priority scheduling but I
don't know if vanilla Linux has these capabilities.
In another era I used to supervise (and work at) the development of
real-time data-access systems and we did a lot with tricking plain DOS
to achieve our goal. Windows is too badly programmed to even remotely
achieve such a goal.
Joep

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Burkhard Carstens-3
In reply to this post by Alain Michaud
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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Felipe Monteiro de Carvalho
In reply to this post by Alain Michaud
On 5/30/06, Alain Michaud <[hidden email]> wrote:
>  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.

0.1 miliseconds is a lot of time for a modern computer. My experience
is that even running on a graphical environment with other processes
running, you can get 0.1 milisecond precision without trouble.

In fact you can get much more precision then that. I managed to create
a oscilloscope GUI with Lazarus (the hardware is a ISA board I created
myself) and I can acquire information from the board with microsecond
resolution on windows and linux running X11. So I would say that you
only need device driver tricks or a real time os for extreme
precision, like nanoseconds.

In case you want to take a look here you can find documentation,
source code and screenshots:

http://eletronicalivre.incubadora.fapesp.br/portal/english/oscilloscope/

--
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Vinzent Höfler
On Wednesday 31 May 2006 01:04, Felipe Monteiro de Carvalho wrote:

> 0.1 miliseconds is a lot of time for a modern computer.

Depends. Here[tm] it's still just about 100 I/O-cycles.

> My experience
> is that even running on a graphical environment with other processes
> running, you can get 0.1 milisecond precision without trouble.

You can, yes. But only "most of the time", not "always". The latter is
called real time and no plain vanilla OS can give you that.


Vinzent.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: spin_lock

Burkhard Carstens-3
In reply to this post by Burkhard Carstens-3
Alain, I think I got a personal mail from you, but I deleted it before I
realized that it's not spam (still sleepy :-).
This email is for mailing list only, so any mail not coming from the
mailing list is automatically dropped to the spam folder..
 Could you resend it on the list?

Burkhard


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal