Re: insmod priority

----- Original Message ----- 
From: "Der Herr Hofrat" <[email protected]>
To: "Klemens Matthias Winkler" <[email protected]>
Cc: "RTL Mailing list" <[email protected]>
Sent: Tuesday, September 21, 2004 4:49 AM
Subject: Re: [Rtl] insmod priority


> > Dear list,
> > I am wondering what happens when running more than one real-time
> > Application on an RTLinux System. The second module is loaded by
> > executing the insmod command. Does the insmod process have a lower
> > priority than the already running real-time threads, or will it preempt
> > them? This might especially be a problem when the init_module function
> > needs much processing power.
>
> INsmod is called in non-RT (Linux) context and has lower priority than
> any running RT-task. so if you want to startup a set of rt-tasks in a
> synced way you need to initialize them and then let them all wait
> (i.e. pthread_barier) bofore starting up processing
>
> > Another thing I am not sure about are the fifo handlers. Is the handler
> > called when all real-time threads are idle, or will it preempt them?
>
> a fifo handler will be called when a write to the fifo is done from
user-space
> - this write can't happen if the rt-system is active so the handler can't
> be called unless the rt-system is inactive. a RT-thread will preempt a
fifo
> handler that was triggert from user-space. With the fifos rt-handler it
> depends on who calles the write - the fifos rt-handler will be executed in
> the context of the calling process so it can be preempted by higher
priority
> processes (if interrupted outside of the spinn-lock protected code
sequence)
>

Assuming your RT modules are going to be loaded in a particular order, the
simplest synchronizing solution is to put one (or more) mutexes into the
first one that get released by the last one loaded.  That way they all
"start at once".

    Norm

_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl