Bill hello
I had the same problem several years a go.I made some research about
this so i might shed some light here.
first, you cannot do:
while(1){
foo();
}
the closest thing is:
while(1)
do_softirq()
foo()
}
A similar piece of code can be found at pktgen.c.
Problem is that a processor must walk through a quiesce state, ( see
bovet, understaning the linux kernel).
Now, This is how we solved it. we divided the solution to two.
1. UP systems.
2. SMP/SMT systems.
in a UP system I did:
while(infinite)
rtc_read
foo()
the RTC clock us programmed in 8K HZ. you can use HPET as well.
2. SMP/SMT systems.
The solution is here a bit more complicated, and it depends on
your application requirements. mine was soft real time.We came with a
solution that I call today: offsched. offsched stands for offline
scheduler ( http://sos-linux.svn.sourceforge.net/viewvc/sos-linux/offsched/trunk/Documentation/).
It is based on Linux ability to hot un/plug a processor. I simply
offload a processor ( only in an SMP/SMT systems) and assign it a
service. Incase you wish to understand more, I suggest you read
OFFSCHED.pdf and OFFSCHED-RT.pdf files.
Currently, I implemented a 1us timer, and RTOP ( remote top).
Raz
On Mon, Apr 13, 2009 at 8:02 PM, Greg KH <greg@xxxxxxxxx> wrote:
> On Mon, Apr 13, 2009 at 08:34:37AM -0700, Bill Jones wrote:
>> I created some code in the kernel that loops until some condition becomes true, i.e.
>> while(!condition) { //do nothing}
>
> Congratulations, you just hung your kernel :)
>
>> Now, in userspace, I created a bunch of threads using pthreads, some
>> of which will change that condition to be true (by making a system
>> call that will change its value in the kernel). However, when I run
>> this code, my entire computer freezes up and continues to loop to
>> infinity.
>
> That's because you are not allowing the kernel to do anything while in
> that loop. Only if you have a multi-processor machine do you have a
> chance to do this.
>
>> This does not fit my understanding of how userspace->kernel threads
>> and the scheduler works (I am using 2.6.28 kernel). I was under the
>> impression that when I created a userspace thread using pthreads, the
>> kernel would implicitly create a kernel thread for each of these. Now,
>> the scheduler will eventually context switch out the kernel thread
>> when its time quanta runs out, so there should never be the
>> possibility for this loop to sit on the CPU forever and not allow
>> anything else to run.
>>
>> What part of my reasoning above is flawed?
>
> Kernel threads need to give up the processor in order for other stuff to
> be run.
>
> good luck,
>
> greg k-h
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
