On thread scheduling

On thread scheduling

[Heikki Orsila]

Consider a simple embedded system:

void interrupt_handler(void)
{
	...
}

int main(void)
{
	...
}

I would like to "emulate" this system with a workstation to make 
development faster. I would create two threads, one executing the 
main() function, and the other occasionally calling interrupt_handler(). 
Before interrupt_handler() is called, the main() thread should be 
stopped asynchronously.

I looked into pthreads documentation and found only pthread_kill(thread, 
SIGTSTP) to do asynchronous stop, but then I also have to play terminal 
tricks to avoid problems..

Is there are function to just disable scheduling of a single thread 
without having other side-effects (such as terminal stuff)? Functions 
like pthread_disable_scheduling(thread) and 
pthread_enable_scheduling(thread) would be good for this..

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: On thread scheduling

[Matthias Kaehlcke]

El Sat, Sep 15, 2007 at 01:40:00AM +0300 Heikki Orsila ha dit:

> Consider a simple embedded system:
> 
> void interrupt_handler(void)
> {
> 	...
> }
> 
> int main(void)
> {
> 	...
> }
> 
> I would like to "emulate" this system with a workstation to make 
> development faster. I would create two threads, one executing the 
> main() function, and the other occasionally calling interrupt_handler(). 
> Before interrupt_handler() is called, the main() thread should be 
> stopped asynchronously.
> 
> I looked into pthreads documentation and found only pthread_kill(thread, 
> SIGTSTP) to do asynchronous stop, but then I also have to play terminal 
> tricks to avoid problems..
> 
> Is there are function to just disable scheduling of a single thread 
> without having other side-effects (such as terminal stuff)? Functions 
> like pthread_disable_scheduling(thread) and 
> pthread_enable_scheduling(thread) would be good for this..

i wonder if assigning a real time priority with
pthread_setschedparam() to the caller of your interrupt_handler()
function would solve your problem. this way the main() thread is never
scheduled when the interrupt_handler() thread is
runnable. interrupt_handler() should be as short as possible,
otherwise you risk starving of the rest of your systems processes.

-- 
Matthias Kaehlcke
Linux Application Developer
Barcelona

        Representation of the world, like the world itself, is
        the work of men; they describe it from their own point
         of view, which they  confuse with the absolute truth
                          (Simone de Beauvoir)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

Re: On thread scheduling

[Ray Lee]

On 9/14/07, Heikki Orsila <shdl@zakalwe.fi> wrote:
> Consider a simple embedded system:
>
> void interrupt_handler(void)
> int main(void)
>
> I would like to "emulate" this system with a workstation to make
> development faster. I would create two threads, one executing the
> main() function, and the other occasionally calling interrupt_handler().
> Before interrupt_handler() is called, the main() thread should be
> stopped asynchronously.

Are you open to doing something other than pthreads? Using fork() to
get real processes, and then sending a SIGSTOP (and SIGCONT) to the
one running main() should work.

Or emulating the interrupt arrival with a signal, and having
interrupt_handler() be registered as the signal handler. Of course,
you then have to deal with the constraints that come with signal
handlers, so that can be a bit of a pain depending on what you're
trying to do.

Ray

Re: On thread scheduling

[Kyle Moffett]

On Sep 14, 2007, at 18:40:00, Heikki Orsila wrote:
> Consider a simple embedded system:
>
> void interrupt_handler(void)
> int main(void)
>
> I would like to "emulate" this system with a workstation to make  
> development faster. I would create two threads, one executing the  
> main() function, and the other occasionally calling  
> interrupt_handler().  Before interrupt_handler() is called, the main 
> () thread should be stopped asynchronously.

Actually you probably just want to do this with an ordinary single- 
threaded program.  Just do your main() thing normally and schedule a  
signal-based timer at program start (or whenever you actually set up  
your periodic interrupt source);  the timer signal-handler will act  
as the interrupt handler.  Alternatively you could have 2 threads  
where the *only* thing the second thread does is a timed poll() loop  
on an FD where it reads commands from the main thread.  When the main  
thread wants to change the interval-between-interrupts or some other  
interrupt configuration it writes the info down the FD to the  
alternate thread which actually sets up the change.  The main program  
then continues running and periodically receives its SIGUSR1 or  
whatever from the other thread and uses that as the interrupt.

Cheers,
Kyle Moffett