| Knowledgebase Why does OFM stop and restart processors on a multi-processor
NetWare system when its NLM loads or unloads? When OFM.NLM loads or unloads, it stops all but one processor on a multi-processor NetWare system (processor zero remains active) so Open File Manager can register its file system hooks. All processes that were running on other CPUs are temporarily reassigned to CPU zero. This stopping of processors, inserting hooks, and restarting processors takes about one second. Processes that were moved to processor 0 will still be running, but will run a little slower until this procedure is finished. After Open File Manager's hooks are registered, any CPUs that Open File Manager disabled are immediately re-enabled. The OS then migrates processes to the re-enabled CPUs. The reason for this temporary switch/hook/switch-back procedure is to avoid a potential abend on a very busy SMP (Symmetric Multi-Processing) system where a CPU may be calling a hook while that hook is being removed by Open File Manager running on another CPU. Here's an example of how this works: Let's say a NetWare multi-processor system has processors 0, 1, and 3 enabled. When OFM.NLM loads or unloads, it stops processors 1 and 3, and all processes that were running on them are temporarily reassigned to processor 0. Open File Manager installs its hooks, re-enables processors 1 and 3, and the OS then migrates processes back to the re-enabled CPUs. This procedure is both prudent and safe since NetWare does not use preemptive scheduling, meaning it does not put a process to sleep while it runs something else. With everything running on CPU 0 during Open File Manager's hook registration procedure, a hook that is partially removed cannot be called by something from another process, and an abend will be avoided. NOTE: This problem applies to SMP systems only; it does not apply to systems with a single CPU only.
|
Resource Center |