> On Fri, Sep 17, 1999 at 09:28:47AM -0700, Jerry Gardner wrote: > > Wojciech Zabolotny writes: > > > Hi All! > > > > > > I have yet another "real time" question. > > > Is it possible to make a part of my program a "critical section", so > that > > > during execution of this part of code my program can not be > suspended? > > > I'd like to be able to send a data through the serial port at the > known time, > > > > As far as I know, there is no way to do this in a user program. The > > reason is simple, Linux is a multiple user system and if any random > > user could do this, they could write a program that enters a crital > > section and then loops forever. Such a program would effectively lock > > the computer up forever. > > I agree, but what about the root's processes? > > > You can easily write code that is non-preemptable in the kernel, > > however. > > Well, but in the kernel I can't use the "write(ComFd,&c,1)". > Am I wrong? (I hope I've missed something) > I'm just trying to use Linux for a kind of realtime data processing, > and I'm trying to avoid RT Linux... > -- > Wojciech Zabolotny > [EMAIL PROTECTED] > As an old realtime programmer, I need to comment on a few things...
If you do a dispatch lock, you can't do anything that might cause your process to suspend. If you do, most real time systems will abort the program with some kind of resource error. If your dispatch locked program waits on io, the entire computer comes to a halt. The kernel runs but nothing else does. You probably want to use real time priorities and a real time scheduler. Then you can make sure that your program will receive service when it needs it. However, you will probably have to set up a real time shell and leave it logged in on the console. If your program gets caught in a loop, there would be no way to do anything unless you had a shell already logged in at higher priority, or you could get a signal to it. If your program runs as a daemon, you need a shell to send the signal since your prog will be detached from a controlling term. Once your program is bullet proof, you can do away with the real time shell. Even with a real time scheduler, there are certain latencies associated with interrupts, context switching, etc. With a real time system, you get deterministic response. Most real time unix implementations are not very good at this. It usually takes a specially written kernel to handle things in a deterministic fashion. There are several commercial systems (Qnx, and others) that will do what you want. I have no idea if RTLinux can. If the general purpose real time kernels are not good enough, then you have to hit the hardware and do it yourself. jim