I am starting an academic project to evaluate a multiprocessor real-time
scheduling approach. To save time, we are building the scheduler as a thread
package on Neutrino 6.2, which is running on a 4-processor i686 SMP.
Due to the smoke and mirrors needed to pull this off, I need to implement my
own context switching code and am having problem avoiding segmentation
violations (probably due to how Neutrino using the MMU). Does anyone know of
source code that already does this successfully under x86 and Neutrino that
I can look at as a model?
Philip Holman <holman@cs.unc.edu> wrote:
I am starting an academic project to evaluate a multiprocessor real-time
scheduling approach. To save time, we are building the scheduler as a thread
package on Neutrino 6.2, which is running on a 4-processor i686 SMP.
Due to the smoke and mirrors needed to pull this off, I need to implement my
own context switching code and am having problem avoiding segmentation
violations (probably due to how Neutrino using the MMU). Does anyone know of
source code that already does this successfully under x86 and Neutrino that
I can look at as a model?
I am not aware of any user-space thread packages on QNX. But there shouldn’t
be anything special going on under Neutrino that would stop something from
working.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
I thought this would be the case also. However, I’ve tried variations on
context switching code taken from some Linux variants and also from the XINU
OS, both of which run on i86 hardware, but have been unsuccessful.
It could be that I’m just making a newbie mistake (I generally try to avoid
assembly language programming), but I cannot seem to determine the cause of
it.
“Chris McKillop” <cdm@qnx.com> wrote in message
news:bmukg5$1fo$1@nntp.qnx.com…
Philip Holman <> holman@cs.unc.edu> > wrote:
I am starting an academic project to evaluate a multiprocessor real-time
scheduling approach. To save time, we are building the scheduler as a
thread
package on Neutrino 6.2, which is running on a 4-processor i686 SMP.
Due to the smoke and mirrors needed to pull this off, I need to
implement my
own context switching code and am having problem avoiding segmentation
violations (probably due to how Neutrino using the MMU). Does anyone
know of
source code that already does this successfully under x86 and Neutrino
that
I can look at as a model?
I am not aware of any user-space thread packages on QNX. But there
shouldn’t
be anything special going on under Neutrino that would stop something from
working.
chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Philip Holman <holman@cs.unc.edu> wrote:
PH > I am starting an academic project to evaluate a multiprocessor real-time
PH > scheduling approach. To save time, we are building the scheduler as a thread
PH > package on Neutrino 6.2, which is running on a 4-processor i686 SMP.
PH > Due to the smoke and mirrors needed to pull this off, I need to implement my
PH > own context switching code and am having problem avoiding segmentation
PH > violations (probably due to how Neutrino using the MMU). Does anyone know of
PH > source code that already does this successfully under x86 and Neutrino that
PH > I can look at as a model?
I’m sorry I don’t have any suggestion to offer about your problem.
I was wondering however how valid it is to do a performance based
research project involving contect switching on top of an OS that is
already going to be doing that kind of thing behind your back.
In addition to thread scheduling, are you trying to do your own memory
management too? Again, I think you’re just asking for trouble trying
to defeat the OS’s own routines for that. Unless you grab one huge
chuck of memory at the beginning and wrote your own memory primitives
to manage allocation/deallocation.
All that aside, Good luck and have fun! It does sound like an
interesting project.
–
Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net
Great question. (One I’ve had to answer a lot.) Most of my research has been
on hard real-time systems. This project is focusing on producing a valid
performance measurement and not on providing a full-blown OS. The tasks we
will be using will be benchmarks and toy apps intended to represent
different types of applications.
The approach I’m investigating currently only supports basic microkernel
services(scheduling and synchronization); we will be implementing those
services ourselves. The thread package that we are implementing is more
accurately an executive in that the code for the threads will be statically
compiled in. In addition, we do intend to use statically allocated memory to
prevent interference from the Neutrino services.
Actually, we surveyed around 10 OSes to select one to use for this project
and selected Neutrino based on it design. IMO, it gives us the best control
over the disruptiveness of the OS services. When running the experiments, we
intend to strip the system down as much as possible to ensure that Neutrino
is basically just performing thread scheduling. This includes disabling disk
I/O services (at least temporarily). Such a plan is tricky, I realize, but
is seemingly the best approach available to us at the moment.
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bn0mko$hlf$1@inn.qnx.com…
Philip Holman <> holman@cs.unc.edu> > wrote:
PH > I am starting an academic project to evaluate a multiprocessor
real-time
PH > scheduling approach. To save time, we are building the scheduler as a
thread
PH > package on Neutrino 6.2, which is running on a 4-processor i686 SMP.
PH > Due to the smoke and mirrors needed to pull this off, I need to
implement my
PH > own context switching code and am having problem avoiding
segmentation
PH > violations (probably due to how Neutrino using the MMU). Does anyone
know of
PH > source code that already does this successfully under x86 and
Neutrino that
PH > I can look at as a model?
I’m sorry I don’t have any suggestion to offer about your problem.
I was wondering however how valid it is to do a performance based
research project involving contect switching on top of an OS that is
already going to be doing that kind of thing behind your back.
In addition to thread scheduling, are you trying to do your own memory
management too? Again, I think you’re just asking for trouble trying
to defeat the OS’s own routines for that. Unless you grab one huge
chuck of memory at the beginning and wrote your own memory primitives
to manage allocation/deallocation.
All that aside, Good luck and have fun! It does sound like an
interesting project.
–
Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net