RE: [OT] How to make a "critical section" in user program?
> 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
> wzab@ise.pw.edu.pl
>
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
Reply to: