Filling up epics queue / Multi threading on linux

[Emmanuel Mayssat <emmanuel_mayssat@lynceantech.com>]

This brings up an interesting point.
Another interesting question I wanted to ask. 

[Read below]

> > 3/ Bus conflict
> > 	There are also bus conflict I want to minimize
> > 	(several devices on same gpib bus, etc. )
> 
> What is to prevent the overload or the bus conflict from occuring at the
> most critical time, i.e. when many things are changing and your scan rates
> are all at their maximum?

Nothing can prevent conflict, but you can minimize their number.
The way to resolve this is of course with callbacks.
There should be no critical time with gpib devices ;-) readback should
be assumed as asynchronous.
Changing scan rate will (theoretically) enable the system to converge
toward a stable state ( read below when too many callbacks/processing at
once) 

My follow up question is let's assume that I have a device with a scan
rate of .1 sec, but its processing take let's say 1 sec. The device may
or may not be programed as asynchronous.
I use redhat linux, or fedora ( not a real time OS )
let's assume that some records are trying to access the same bus ( but
the bus is most of the time busy ) at a scan rate of .1 sec.

In other words I am trying to do to many things at once ;-)

Now, what happens to the .1 sec epics queue ?
Does it fill up?
Does it crash the ioc?
What happens?

It seems that even if the records are not conflicting for the same
bus/resource, multi threading doesn't kick in the way I thought it
should. Can I have multi threading on a linux platform ?
If so, the epics queue should never "fill up", but my experience seems
to show otherwise.

Any idea?
 
-- 
Emmanuel Mayssat
Cell: 650/793-0626
Lyncean Technologies, Inc.
"See the invisible"